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Azt hittem, megúszhatom. A jóslást. De hiába 
lapítottam, sunyítottam, már január első napján 
megérkezett az első felkérés, hogy mondjam 
meg, mit hoz a jövő, a következő év az informa- 
tikában. Mintha belátnék a Microsoft boszor- 
kánykonyhájába! Mintha látnám a jövőt! Látom 
is! Látom a saját jövőmet, a családomét, a köz- 
vetlen környezetemét. Miután az ember fél mé- 
ter sugarú körben mindennek ura, nem is csoda, 
hogy saját sorsát saját elképzelései alapján ve- 
zérli, s látja, formálja a jövőt. De Redmond és 
Amerika kívül van e bűvös körön. Semmi esé- 
lyünk az ott zajló folyamatok befolyásolására, sőt megértésére 
sem. Ami a Microsoft jövőjét illeti az kizárólag egyetlen ember 
látja", azaz formálja, ez Bill Gates, még akkor is, ha külső té- 
nyezők néha megzavarják ebben (per). De jöjjön, aminek jön- 
nie kell, elmondom, mit tudok" a jövőről. 





Feldarabolás 

Sokakat érdekel, vajon végül feldarabolják-e a Microsoftot. Na- 
tív spekulációval arra a következtetésre jutottam, hogy 1) eb- 
ben az évben biztosan nem 2) de ha mégis, akkor sem lesz en- 
nek a lépésnek semmilyen látható hatása sem a Microsoftra, 
sem az informatikára, mert ma már teljesen máshol található a 
cég súlypontja, mint ahol a per kezdetén volt. Az Office, a Win- 
dows és az Internet Explorer megkérdőjelezhetetlen győzelme 
miatt talán nem meglepő, hogy a Microsoft más piacok felé for- 
dult. Ha valami katasztrófa folytán akár mindhármat leválaszt- 
ják a cégről - az is csak levedlett bőr, Alatta már alakul, fejlő- 
dik az új. S több év óta először a meghódítandó piac egy 
egyelőre nem létező piac - a .NET. Nem volt felesleges Billyt ki- 
vonni a napi munkából, láthatóan több ideje marad gondolkod- 
ni. Egészen 1995-ig ért rá gondolkodni: , PC-t minden asztalra" 
mondta, amikor a PC még hobbygép volt. , Minden adatbázis 
megérdemli a relációs adatbáziskezelő motort" amikor az SOL 
alapú kiszolgálók milliárddolláros beruházást igényeltek. ,, 640 
kilobájt mindenre elég lesz...." Tévedni emberi dolog. , Where 
do you want to go today?" Oda, ahol még senki sem járt. 


.NET 

A dotnet többet jelent egyszerű ötletnél. Hosszú évek után ez 
az első ötlet a Microsofttól, mellyel ismét átveszi a jövőformá- 
lást, az egész IT világ szakmai fejlődésének vezetését. Hogy- 
hogy? Hát elveszítette? Igen, el. 1995-ben. Még emlékszem a 
Windows 95 kibocsátása előtti izgalomra, amikor először kínált 
az operációs rendszer világhálót. A Microsoft-féle Bluebird 
kódnevű (erre lehet, hogy már nem jól emlékszem) saját megol- 
dást. És Bill nem vette észre, vagy nem vette komolyan, hogy 
pöttöm cégek egész serege valami Internettel, vagy mivel ját- 
szik. Nem nagy bűn, a CompuServe és az AOL sem viselkedett 
másként. Ám az Internet növekedése elképesztő sebességgel, 
a szokásosan magas IT növekedési rátát messze maga mögött 
hagyva zajlott. Fél év sem kellett hozzá, és a nagyok is sorban 
behódoltak. Behódoltak, és alattvalóvá váltak. Milyen érzés le- 
hetett Billnek, hogy egy piacon nemhogy nem ő vezet, de sen- 
ki nem kíváncsi a véleményére? Megmondom: frusztráló. Az 
Internet volt szinte az egyetlen piac, amit a Microsoft nem 
tudott learatni, hanem keményen megdolgozott az eredmé- 
nyekért. Keményen küzdött. Évek teltek el olyan küzdelem- 
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ben, ami erkölcsileg nagyon sokba került a Microsoftnak. 
Olyannyira, hogy szinte senkinek sem tűntek fel a termékfej- 
lesztésben végbement nagyságrendi pozitív változások. A ter- 
mékek megbízhatósága hihetetlen fejlődésen ment át! Gon- 
doljunk csak az operációs rendszerekre: Windows 3.1, 95, NT, 
2000 - mindegyik fényévekre van az előzőektől! 

Öt kemény év telt el ezen a lélektanilag és egyéb tényezők 
szempontjából is létfontosságú piacon úgy, hogy a Redmon- 
di Óriás hátrányos helyzetben vergődött! Hja, a sok-sok 
pénz nem minden! Nem tudták, hogy mit akarnak, hiányzott 
a vízió, hisz Bill a napi papírtologatással volt elfoglalva. Jó, 
persze lett IIS és Explorer 2.0, 3.0, 4.0 és 5.0, lett Frontpa- 
ge, save as HTML és hasonlók, sőt megindult, és jelenleg is 
tart a hosszútávon életképtelen technológiák kiirtása 
(MAPI, X.400, SMB, NetBIOS és WINS). De semmi új ötlet. Sem- 
mi eget rengető idea öt hosszú éve! De most megszületett! 


.NET mégegyszer 

Ez nem csupán a Windows DNA legújabb ruhája. Ez egy világ- 
megváltó ötlet: nem egyedi PC-k, nem webkiszolgálók, nem 
harminc éve zárt funkcionalitású szolgáltatások, hanem vala- 
mi új. Ahol nem a szolgáltatásokat szabványosítják, hanem 
végre-valahára a fejlesztést, a kapcsolattartást, és az Inter- 
net kiterjeszthetőségét. A .NET teszi azzá az Internetet, ami- 
re termett: infrastruktúrává. Hogy én mennyire gyűlölöm a 
regisztrációs lapokat és a jelszavakat! Hoci nekem Microsoft 
Passport! Hogy mennyi felesleges erőfeszítés megy el arra, 
hogy minden szerencsétlen pizzafutár cég saját maga fej- 
leszt(tet)i ki halál pontosan ugyanazt a térképadatbázist! 
Jöjjenek és sokasodjanak a megaszolgáltatások! És mennyit 
kell kattintgatni! Miért kell a weben bogarásznom ahhoz, 
hogy a wordben kijelölt szanszkrit nyelvű szó magyarrá vál- 
jon? Hol a jobbklatty-translate? Olyan lehetőség manapság 
egyáltalán nincs, hogy a meglévő alkalmazásaim az Internet- 
ről tetszőleges szolgáltató vagány funkcióival kiegészülje- 
nek. Jó, tudom, ActiveX. De nem fogadom el a választ! Hol 
is van az a szanszkrit-magyar ActiveX? Mi a címe? Miért függ 
a szolgáltatás megtalálása az én intuitív keresési kulcs-blöf- 
fölő képességemtől? És ki fizeti meg a guberálással elpaza- 
rolt időmet? Hol a szolgáltatás-lokátor? Lesz! 


LINUX 

Rengeteg jelenlegi, esetleg tudatosan át sem gondolt problé- 
mára hoz megoldást a .NET. A startpisztoly eldördült, az új In- 
ternet lehetőségei minden fejlesztő számára adottak lesznek. 
A .NET egy vezércsillag, és tudom, hogy a Microsoft a megté- 
velyedett báránykáknak is lehetővé fogja tenni, hogy kövessék 
útjukon. Szomorú, de így van, egy csetepatéval kevesebbnek 
örülhetünk 2001-ben: a LINUX nem beveendő bástya többé, 
hanem hátasló. Két évet adok Billnek, hogy mindenki megelé- 
gedésére a LINUX is .NET hordozóvá váljon. S akkor beköszönt 
a világbéke, és mindannyian egymás kebelére borulunk, mi- 
képpen mi is megbocsátunk az ellenünk vétkezőknek, BUÉK. 


Fóti Marcell 
marcellf(onetacademia.net 
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Bill Gates január 6-án, Las Vegas-ban be- 
jelentette a , videojátékok jövőjét", az X- 
Box-ot. ,Az X-Box kimagasló technoló- 
giai paramétereivel, hihetetlen grafikai 
teljesítményével minden kétséget kizá- 
róan a játékkonzolok piacának mércéje 
lesz az elkövetkezendő években. A já- 
tékprogramkészítők a videojátékok új 
világát fedezhetik fel, s olyan játékélményt nyújthatnak a 
videojátékok szerelmeseinek, melyeket korábban elképzelni 
sem lehetett." - mondta Bill Gates. 
Az X-Box játékkonzolt, valamint a hozzá tartozó vezérlő- 
egységet több mint 5000 lelkes videojáték-rajongó és já- 
tékprogram fejlesztő visszajelzéseinek figyelembe vételével 
tervezték. A fekete színű készüléken, mely külalakjában is 
erőt sugároz, egy nagy X betű domborodik, s ennek köze- 
pén található a zöld színű X-Box ,ékszer". 
Az X-Box logóval szintén ellátott vezérlőegység kialakítá- 
sakor a biztonságos irányítás és kényelmes használat volt 
a fő szempont. Végső arculata mögött több ezer tesztelési 
óra munkája rejlik. Egy nyolcutas irányítóegység található 
benne, bal és jobb analóg karok, hat darab színes, nyomás- 
érzékeny analóg gomb, valamint kettős bemenet a memó- 
riakártya és egyéb perifériák számára. 
Bővebb információ: [1] 


Gyártósoron a Microsoft ISA Server 2000 


Elkészül a .NET kiszolgá- . Microsoft 
lócsalád szolgáltatásai- Internet Security 
Bi 8. Acceleration Server 


nak védőbástyáját alko- 
tó Internet Security and Acceleration (ISA) Server 2000 vég- 
leges verziója, amely már a CD másoló üzemekben jár. Az ISA 
Server nagyvállalati szintű tűzfal és Web cache kiszolgáló, 
amely könnyen felügyelhető, biztonságos és gyors Internet 
elérést biztosít bármilyen méretű cég részére. A korábbi 
Proxy 2.0 Serverrel ellentétben az ISA már teljesértékű tűz- 
fal megoldást nyújt, többszintű csomagszűrő szolgáltatással, 
kapcsolat- és alkalmazásszintű szűrési lehetőséggel. Beépí- 
tett VPN és betörésjelző képességekkel rendelkezik, valamint 
képes értelmezni és szűrni az elterjedt Internetes protokollo- 
kat, így például képes kiszűrni a bizonyos kulcsszavakat tar- 
talmazó elektronikus leveleket. 

A többi .NET kiszolgálóhoz hasonlóan kétféle verzióban 
kapható. Az Enterprise változat a nagy internetforgalmú 
nagyvállalatok számára ajánlott. Központosított felügyeleti 
eszközei segítségével még sok telephely esetén is egy szá- 
mitógépről vezérelhetők az egész szervezetre vagy csopor- 
tokra, telephelyekre érvényesíthető biztonsági beállítások. 
Többszintű házirendek segítségével finoman hangolható az 
egyes csoportok, felhasználók, alkalmazások internethozzáféré- 
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se. A nagy rendelkezésre állás érdekében terheléselosztó fürtbe 
is kapcsolhatók a gépek, így tetszőleges terhelésre skálázható és 
hibatűrő képességekkel rendelkező tűzfalmegoldást kapunk. El- 
sősorban üzleti kritikus nagyvállalati környezethez ajánlják. 

A Standard Edition az előbbi verzióhoz hasonló képességekkel 
rendelkezik, a kis és közepes vállalatok számára is elérhető áron. 
A termék a kereskedelemben 2001 első negyedévétől elérhető. 
Bővebb információt a [2] címen találhatnak az érdeklődők. 






Professional 





Február 28.-ig még le lehet tenni az NT4 MCP vizsgákat 
Az NT4-es vizsgák utolsó napjaként megjelölt 2000. december 
31.-i dátumot 2001. február 28.-ára módosította a Microsoft. A 
lépésre azért volt szükség, mert a 2000. év végén elárasztották 
a vizsgázni vágyók a vizsgaközpontokat, akik sok jelentkezőt 
helyhiány miatt egyszerűen nem bírtak regisztrálni a vizsgákra. 
Volt olyan vizsgaközpont, ami december folyamán éjfélig nyit- 
va tartott, így igyekezve kiszolgálni a nem várt igényt. A nagy 
vizsgakedv egyik oka, hogy a Windows 2000-es MCSE fokozat 
megszerzéséhez szükséges 7 vizsga helyett csak 4-et kell leten- 
ni azoknak, akiknek van NT4-es MCSE tanúsítványuk, mert a 7- 
ből 5 vizsgát egy összevont, maratoni vizsgában is letehetik. 
Az NT4-es MCSE vizsgák 2001. december 31.-ig érvényesek, 
tehát aki szeretne élni az összevont 2000-es alapvizsga lehe- 
tőségével, annak még az idén meg kell próbálkoznia az 
összevont (egyébként ingyenes) vizsga letételével. 


Elkészült a Microsoft XML Parser 3.0 

Hosszú várakozás után, az XML fejlesztők nagy örömére elké- 

szült a Microsoft XML Parser (MSXML) 3.0-s verziója. Ez a ver- 

zió igen jelentős fejlesztés a Windows 2000-ben található 

2.5-ös verzióhoz képest. Milyen újításokat találhatunk benne? 

"0 Teljes támogatás a World Wide Web Consortium (W3C) 
Extensible Stylesheet Language Transformations 
(XSLT)-hoz és XML Path Language (XPath)-hez 

"8 Teljes COM felület a Simple API for XML (SAX2) támo- 

gatáshoz, amelyet Visual Basic, Visual C---, ill. script- 

nyelvekből könnyen elérhetővé tettek. 

A Document Object Model (DOM) és a névtér támogatás 

továbbfejlesztése 

Kiszolgálóoldali alkalmazások fejlesztéséhez biztonsá- 

gos XML elérés HTTP protokollon keresztül 

2 Az XML 1.0 és a névtér 1.0-hoz kapcsolódó tesztfeltéte- 

lekhez való nagyon jó alkalmazkodás 

Sok hibajavítás és teljesítmény továbbfejlesztés 

A parser komponens, a dokumentáció és az SDK letölt- 

hető a [3] címről. 


b 
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Elkészült a 3. javítócsomag az SOL Server 7-es verziójához 





Az új szervizcsomag az SOL Server 7-hez és a Microsoft Da- 
ta Engine 1.0-hoz nyújt hibajavításokat és fejlesztéseket. 
Javításokat tartalmaz az adatbázismotorhoz, az Enterprise 
Manager-hez, valamint az OLEDB és ODBC szolgáltatókhoz. 
Külön javítócsomag készült az alaptermékhez és az OLAP 
szolgáltatásokhoz, így fölöslegesen nem kell letölteni azt, 
amelyiket nem használnák az adott környezetben. 

A szervizcsomag által javított hibák leírása valamint a le- 
töltési lehetősége a [4] címen érhető el. 


Kiadás előtt a Biztalk 2000 

A CD gyártósorokon van a .NET ki- 
szolgálócsalád utolsó 2000-es épí- 
tőkockája, a Biztalk Server 2000. A 
termék az informatikai piac egyetlen olyan terméke, amely 
összefogja a nagyvállalati alkalmazásintegrációt (Enterprise 
Application Integration, EAT), üzlet-üzlet kapcsolatot (Busi- 
ness-to-business) és Biztalk Orchestration technológiát, ez- 
zel segítve olyan üzleti folyamatok fejlesztését, amelyek al- 
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kalmazásai átfognak több nagyvállalatot is. Nem kevesebbet 
—g vállal fel, mint hogy ,megoldja a mai IT ipar leg- 
nagyobb nehézségét, az elszigetelt és különböző- 
képpen működő alkalmazások összeintegrálását, 
egy közös megoldás érdekében". 

Az XML-re épülő kiszolgáló kétféle változatban, En- 
terprise Edition és a Standard Edition kiszerelésben 
kapható. Az Enterprise változat korlátlan számú kül- 
ső partner és belső alkalmazás integrációjára használható. El- 
sősorban nagyvállalatok részére használható ki jól, ahol a nagy 
rendelkezésre állás érdekében fürtözött módon, valamit a telje- 
sítmény érdekében sokprocesszoros rendszerekre is telepíthető. 
A Standard változat kis és közepes cégek számára készült, 
és maximum 5 külső partner és 5 belső alkalmazás össze- 
fogására használható. 

A szoftverek 2001. januárjában már a kereskedelemben is 
elérhetőek lesznek. 

További információk: [5] 


A cikkben használt URL-ek: 
[1] http://www.xbox.com/ 








[2] http://www.microsoft.com/ISAServer/ 

[3] http: n.microsoft.com/xml/general/xmlparser. 
[4] 8 icri n 

[5] http://www.microsoft.com/biztalk 
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WINDOowSsS 2000 


Policy sablon- 


fájlok szerkesztése 


DropDownList 

Alkalmazásával egy legördíthető lista jön létre. A lista ele- 

meit a sablonfájlban kell meghatároznunk. A System Policy 

Editor felületén keresztül tehát nem tudjuk az elemeket 

megváltoztatni. DROPDOWNLIST esetében az alábbi paran- 

csokat használhatjuk: 

"8 REOUIRED: A beállítás engedélyezésekor kötelező értéket 
megadni. 

"8 ITEMLIST: Ezzel a paranccsal tudjuk meghatározni a lista 
elemeit. Az elemek nevét a NAME kulcsszót követően 
szöveges változóval adjuk meg. Mivel a bejegyzés érté- 
ke nem a kiválasztott elem lesz, ezért minden elem után 
fel kell tüntetnünk a megfelelő értéket is: 


POLICY !!Sample7 
KEYNAME "ADMTesztiDropDownList" 
PART !!DropDownList Part DROPDOWNLIST 
VALUENAME "DropDownList Value" 
ITEMLIST 
NAME !!Elementl VALUE NUMERIC 10 
NAME !!Element2 VALUE !!Element2 
NAME !!Element3 VALUE NUMERIC 35 
DEFAULT 
END ITEMLIST 
END PART 
END POLICY 


A példában a legördíthető listának három eleme lesz. Az el- 
ső kiválasztásakor a  DropDownList Value néven 
REG DWORD típusú bejegyzés jön létre a regisztrációs adat- 
bázisban, melynek értéke 10 lesz. Ha REG SZ típusú bejegy- 
zést szeretnénk létrehozni, akkor a NUMERIC kulcsszó nél- 
kül kell az értéket feltüntetnünk. Ilyenkor lehetőségünk 
van az elem nevével megegyező értékű bejegyzést létrehoz- 
ni a regisztrációs adatbázisban (lásd a fenti példa második 
elemét). A DEFAULT kulcsszóval meghatározhatjuk, hogy a 
házirend engedélyezésekor a bejegyzés alapértelmezésben 
milyen értéket kapjon. 


ComboBox 
Szintén egy legördíthető lista jelenik meg a Policy Editor 
felhasználói felületén. Eltérően a DROPDOWNLIST típustól, 
a listából kiválasztott elem neve lesz a bejegyzés értéke a 
regisztrációs adatbázisban. Ezen túlmenően a COMBOBOX 
esetében nemcsak a listából választhatunk, hanem más ér- 
téket is beírhatunk. A bejegyzés típusa minden esetben 
REG SZ lesz. Az EDITTEXT esetében leírt parancsok a 
COMBOBOX esetében is használhatóak, de ezeken kívül még 
két utasítás áll rendelkezésünkre: 
"8 SUGGESTIONS: A listában megjelenő értékek meghatá- 
rozására szolgál. Az értékeket szóközzel elválasztva kell 
feltüntetni a sablonfájlban, és csak akkor kell idézőjel- 
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be tenni őket, ha szóköz is szerepel bennük. A felsoro- 
lást az END SUGGESTIONS zárja. 

B NOSORT: Alapértelmezésben a lista elemei névsorban 
tűnnek fel. Ezt a parancsot akkor érdemes használni, ha a 
felsorolásuk sorrendjében szeretnénk megjeleníteni őket. 


POLICY !!Sample8 
KEYNAME "ADMTesztiComboBOox" 
PART !!ComboBox Part  COMBOBOX 
VALUENAME "ComboBox Value" 
SUGGESTIONS 
Egy Hat Tizenegy Kilenc 
END SUGGESTIONS 
END PART 
END POLICY 


Numeric 
Ezzel a típussal egy szerkeszthető mezőt hozhatunk létre, 
amelynek értéke csak egész szám lehet. A mezőben szerep- 
lő értéket nyilak segítségével növelni és csökkenteni is le- 
het. A bejegyzés típusa REG SZ vagy REG DWORD lesz a re- 
gisztrációs adatbázisban. Ennél a típusnál az alábbi paran- 
csok használhatóak: 

"I MAX cértéks: Meghatározhatjuk, hogy mekkora legyen a 
mezőbe írható maximális érték. Alapértelmezésben ez a 
szám 9999. 

"I MIN cértéks: A mezőbe írható szám legkisebb értékét 
adhatjuk meg. Alapértelmezésben ez az érték 1. 

2 SPIN cértéks: Meghatározhatjuk, hogy a nyilakkal 
mennyivel növelhető, illetve csökkenthető a mezőben 
szereplő érték. Az utasítás hiányában egyesével változ- 
tathatjuk a mezőben szereplő számot. Ha nulla értéket 
írunk a parancs után, akkor a nyilak nem jelennek meg 
a mező jobb oldalán. 

b DEFAULT cértéks: Megadhatjuk, hogy a beállítás enge- 
délyezésekor milyen érték jelenjen meg a mezőben. 

"0 REOUIRED: Ezzel a paranccsal kötelezővé tehetjük a mező 
kitöltését. 

"2 TXTCONVERT: A mezőbe továbbra is csak számok írhatóak, 
de a bejegyzés REG SZ típusú lesz a regisztrációs adat- 
bázisban. 


POLICY 1!Sample9 
KEYNAME "ADMTesztWWumeric" 
PART !!Numeic Part — NUMERIC SPIN 5 
VALUENAME "Numeric Value" 
DEFAULT 20 
MIN 0 
MAX 30 
END PART 


END POLICY 
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Ez a PART típus lehetőséget ad számunkra, hogy egy kulcs 
alatt több bejegyzést hozzunk létre, illetve változtassunk 
meg a felhasználói felületen keresztül. Korábban már szóba 
került, hogy a LISTBOX esetében nem a VALUENAME kulcs- 
szóval határozzuk meg a bejegyzés nevét. Erre két különbö- 
ző lehetőség is kínálkozik. Létrehozhatunk olyan LISTBOX-ot, 
ahol csak a bejegyzés értékét kell megadnunk, az elnevezést 
a Policy Editor automatikusan rendeli hozzá az értékhez: 


be üeg BE 


USTBOX 
1 











hel gsesege egye ssgel el 


A LISTBOX másik típusánál viszont az érték mellett a be- 
jegyzés nevét is meg kell határoznunk: 


ELTETT ZTT ESTE NKBEKEKENEEEE 2] 
m 
Value Name Value 
Titbox Value ) 10 Cancel 
Add. 
tej sss sssszeszeszzese vi 





A regisztrációs adatbázisban mindkét esetben REG SZ tí- 
pusú bejegyzések jönnek létre. A LISTBOX esetében a kö- 
vetkező parancsok használhatóak: 

"0 VALUEPREFIX celőtagz: Az előtag a bejegyzés nevének 
meghatározására szolgál. A System Policy Editor auto- 
matikusan egy sorszámot fűz az előtagként meghatáro- 
zott karaktersor után, attól függően, hogy hányadik 
helyen szerepel az adott bejegyzés a LISTBOX-ban. Pél- 
dául VALUEPREFIX ValueName esetén a regisztrációs 
adatbázisban ValueName1, ValueName2, ValueName3 
stb. néven jönnek létre a bejegyzések. , Üres" karakter- 
sort (, ") is megadhatunk előtagként. Ilyenkor bejegy- 
zések elnevezése ,, 1", ,27, ,3" stb. lesz. 
EXPLICITVALUE: Ennek az utasításnak a használatakor 
nemcsak a bejegyzés értékét, hanem a nevét is meg 
kell adni a felhasználói felületen keresztül. Nem hasz- 
nálható a VALUEPREFIX utasítással együtt. 

ADDITIVE: Alapértelmezésben a regisztrációs adatbázis 
megfelelő kulcsa alatt csak a LISTBOX-ban megadott bejegy- 
zések fognak szerepelni, a házirend végrehajtása során az 
összes korábbi kitörlődik. Az ADDITIVE parancs használatá- 
val a más forrásból származó bejegyzések megmaradnak. 


b 


POLICY !!Samplel0 

KEYNAME "ADMTesztlListBOx" 
PART !!ListBox Part — LISTBOX 
EXPLICITVALUE 

END PART 


END POLICY 
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Text 

Ez a PART típus arra szolgál, hogy az egyes beállítások 
használatához magyarázó szöveget tudjunk megjeleníteni 
a Policy Editor felhasználói felületén. Alkalmazásakor te- 
hát a regisztrációs adatbázisban nem keletkezik bejegyzés. 
Használata nagyon egyszerű. A PART kulcsszó után lévő 
szöveges változó értéke lesz a magyarázó szöveg. Termé- 
szetesen a szöveges változó értékét a korábbiakhoz hason- 
lóan most is a (stringsj szekcióban határozzuk meg. 


POLICY !!Samplell 
PART !!Partl EDITTEXT 
VALUENAME "Samplell Value" 
MAXLEN 6 
END PART 


PART !lEditText Tipl TEXT 
END PART 
PART !!lEditText Tip2 TEXT 
END PART 

END POLICY 


Istrings] 
EditText Tipl - "A mezőbe maximum hat karakter 
irható" 


EditText Tip2 - "Példa a Text Part típusra" 


Hogyan fogjunk hozzá az új sablonfájl készítéséhez? 
Új sablonfájl elkészítésének gondolata általában akkor me- 
rül fel, amikor találunk egy olyan beállítást, amit szeretnénk 
központilag kezelni, de még nem szerepel a házirendben. 
Legfontosabb lépés, hogy megtaláljuk a regisztrációs adat- 
bázisban a megfelelő bejegyzést vagy bejegyzéseket, és ki- 
nyomozzuk, hogy mikor, milyen értékeket vehet fel. Miután 
végeztünk ezzel a sok esetben időigényes feladattal, akkor 
elkezdhetjük a regisztrációs adatbázis változásait átalakíta- 
ni olyan formába, hogy a sablonfájl szintaktikájának megfe- 
leljen. Előfordulhat azonban olyan eset is, hogy valamelyik 
meglévő házirend beállítást szeretnénk átalakítani. Elkerü- 
lendő, hogy a kliensek működésében véletlen hiba folytán 
zavar keletkezzen, melegen ajánlott a sablonfájlt tesztrend- 
szerben kipróbálni. Csak akkor használjuk éles rendszerben, 
ha meggyőződtünk róla, hogy minden esetben jól működik. 
Sok felesleges munkától kímélhetjük meg magunkat, ha a 
változtatásainkat gondosan leteszteljük. 

A sablonfájlok szerkesztésére bármilyen text editor (pél- 
dául NotePad) alkalmas. A szintaktikai hibák megtalálásá- 
hoz azonban nem árt, ha van kéznél olyan szerkesztő prog- 
ram, amely kijelzi a sorok számát. A sablonfájl betöltése- 
kor a Policy Editor ellenőrzi, hogy az utasításokat megfe- 
lelő helyen és módon használtuk-e. Amennyiben hibát ta- 
lál, akkor egy rövid üzenetben tájékoztat, hogy melyik sor- 
ban bukkant rendellenességre: 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 01. 


WINDows 2000 





The following error occurred ín C:ÍWINNTJinf winnt2. adm on fine 491 
keyword 


Error 2000 Unexpected 


Found: Part 
Expected: KEYNAME, CATEGORY, POLICY, ENO 


The file can not be loaded. 








A regisztrációs adatbázisban természetesen nem mindegyik 
bejegyzés érvényes a különböző Windows operációs rend- 
szereknél. Ha a számítástechnikai rendszerünk ebből a 
szempontból nem egységes, akkor gondolnunk kell arra is, 
hogy például a Windows 2000-re vonatkozó bejegyzés ne 
kerüljön mondjuk a Windows NT 4.0 vagy a Windows 98 
operációs rendszeren futó számítógép regisztrációs adatbá- 
zisába. Ezt a problémát az Hif version, ttendif utasításokkal 
lehet megoldani: 


$if version cz 2 
CLASS User 
CATEGORY !!W2K 
POLICY !!GPADM 
KEYNAME "AdmTeszt" 


PART !!Msgl 
END PART 


TEXT 


END POLICY 
END CATEGORY 
tendif 


$if version 575 3 
CLASS User 
CATEGORY !I!GPTest 
KEYNAME "AdmTeszt" 
POLICY !!Samplel2 
VALUENAME "if version" 
END POLICY 
END CATEGORY 
tendif 


(Istrings] 


W2K - "Windows 2000 operációs rendszerhez" 
GPADM -— "Group Policy sablon" 

Msgli - 
4  Editorral" 


"Ez a sablon nem használható System Policy 


GPTest - "Group Policy teszt" 
Samplel2 - "Példa 12" 


Ha a fenti példában szereplő sablonfájl mintát a System Po- 
licy Editorral töltjük be, akkor az tif version cz 2, Hendif 
által határolt rész jelenik meg. Így a felhasználói felületen 
csak egy figyelmeztető üzenet tűnik fel. A csoportos házi- 
rend esetében viszont az ttif version s- 3 utáni konkrét 
beállítást tartalmazó szakasz lép életbe. Ezáltal elkerülhető 
tehát, hogy a Windows 2000 előtti operációs rendszerekkel 
működő számítógépekhez olyan beállítás jusson el, amely- 
nek semmilyen hatása sincs a működésükre. 
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Házirend beállítás átalakítása egy konkrét példán keresztül 
A magasabb szintű biztonsági beállítások tervezésekor fel- 
merülhet a programfuttatás korlátozásának igénye. A Sys- 
tem Policy révén beépített eszközökkel, központilag tudjuk 
megadni, hogy a felhasználók mely programfájlokat indít- 
hatják el. A beállítás alkalmazásakor több probléma is fel- 
merül. Egyrészt a korlátozás megkerülhető. Például com- 
mand promptból (cmd.exe) vagy az Office makróból indított 
programokra nem vonatkozik a tiltás. A felhasználói jogok 
további korlátozásával azonban lényegesen megnehezíthet- 
jük a szabály kijátszhatóságát. Másrészt a beállítás működé- 
séből fakadóan nagymértékben megnőhetnek a rendszergaz- 
dai feladatok. Számos programot mindenki számára hozzá- 
férhetővé kell tenni, bizonyos alkalmazásokat viszont csak 
néhány dolgozó használhat. Ez utóbbi programok engedé- 
lyezését csoportok szintjén érdemes szabályozni. Ennek ér- 
telmében minden általánosan nem használt alkalmazáshoz 
létre kell hoznunk egy globális csoportot. Természetesen a 
házirendben minden csoportnak csak a hozzá tartozó prog- 
ramfájlok futtatását engedélyezzük. A gondok valójában ak- 
kor kezdődnek, amikor egy dolgozó két csoportnak is tagja 
lesz. A házirend végrehajtása során azt fogjuk tapasztalni, 
hogy a felhasználó csak az egyik csoportnak engedélyezett 
programfájlokat tudja elindítani. Mivel a két csoportban 
ugyanahhoz a beállításhoz eltérő értékeket adtunk meg, 
ezért a System Policy csak a rangsorban előrébb lévő csopor- 
tét veszi figyelembe. (A System Policy Editor működésének is- 
mertetésekor már volt róla szó, hogy a sorrendet az Options 
menü Group Priority menüpont alól elérhető párbeszédablak- 
ban határozhatjuk meg.) Kézenfekvő megoldásnak tűnik, 
hogy egy felhasználó csak egy csoportnak legyen a tagja, de 
ezáltal lényegesen több csoportot kell létrehozni, ami meg- 
nehezíti a rendszergazdák munkáját. A sablonfájl átalakítá- 
sával azonban megoldható, hogy a System Policy fésülje 
össze az egyes csoportoknak megadott értékeket. 

A programok futtatásának korlátozása a common.adm nevű 
sablonban található: 


POLICY !i!RestrictApps 
KEYNAME 
SoftwarelMicrosoft WindowsNCurrentVersionlPolicies 
4 NExplorer 
VALUENAME RestrictRun 
PART !!RestrictAppsList LISTBOX 
KEYNAME 
SoftwarelMicrosoftWWindowsNCurrentVersionlPolicies 
3  VExploreríRestrictRun 
VALUEPREFIX "" 
END PART 
END POLICY 


A korlátozás engedélyezésével az Explorer kulcs alatti Rest- 
rictRun nevű bejegyzés értéke 1 lesz. Az engedélyezett 
programok neve az ExplorerMRestrictRun kulcs alatt találha- 
tó. A VALUEPREFIX ,," utasítás miatt a RestrictRun kulcs 
alatt , 17, ,27, ,3" stb. néven jönnek létre a bejegyzések. 

Az egyszerűség kedvéért tegyük fel, hogy a Notepad, vala- 
mint a Calculator programok elindítását szeretnénk engedé- 
lyezni. Vannak olyan felhasználók, akik csak az egyik, má- 
sok mindkét programot használhatják. A beállítások érvény- 


tech.net! 


WINDows 2000 


re jutásának szabályszerűségeit ismerve az alábbi problé- 
mákat kell megoldanunk: 

Biztosítanunk kell, hogy a két programhoz tartozó bejegyzés 
semmilyen körülmények között ne íródjon ugyanolyan néven 
a regisztrációs adatbázisba. Ezáltal elkerülhető, hogy a házi- 
rend végrehajtásakor valamelyik bejegyzés felülíródjon. 
Mivel azok a beállítások, amelyek nem fedik át egymást, a 
csoportok szintjén összeadódnak, a sablonfájlt úgy kell 
megszerkesztenünk, hogy mindegyik program futtatásának 
engedélyezéséért külön beállítás feleljen. 


CATEGORY !!RestApps 
KEYNAME "ADMTesztiSampleApps" 


POLICY !!Notepad 


PART !!1 EDITTEXT 
VALUENAME "1" 
END PART 
END POLICY 


POLICY !!Calculator 
PART!!1 EDITTEXT 
VALUENAME "5" 
END PART 
END POLICY 
END CATEGORY 


Ezzel a megoldással a korábban megfogalmazott mindkét 
feltételt sikerült teljesítenünk. Egyrészt a Notepad és a Cal- 
culator futását külön jelölőnégyzettel tudjuk engedélyezni. 
Másrészt mindegyik program önálló bejegyzésnévvel rendel- 
kezik. Mivel erre a feladatra a LISTBOX nem alkalmas, ezért 
kellett az EDITTEXT típust alkalmaznunk. A házirend beállí- 
tásakor ügyelnünk kell arra, hogy a Notepad csoportnál a 
Calculatorhoz tartozó jelölőnégyzetet hagyjuk szürkén (nem 
konfigurált állapot) . Természetesen ugyanez fordítva is igaz. 


KETMETET TETTE] HET 
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Notepad 
- UJ Piogramok futtatása 
EJ Notepad 
E) Calculator 


Settings for Notepad 


1: [notepad exe 








5 Programfuttatás engedélyezése 
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A System Policy működésének sajátosságából fakadóan 
még egy problémát kell leküzdenünk. Ha az egyik felhasz- 
nálót kivesszük mondjuk a Notepad csoportból, akkor ta- 
pasztalni fogjuk, hogy a programhoz tartozó bejegyzés 
nem törlődik a regisztrációs adatbázisból. Ezt a gondot a 
következőképpen orvosolhatjuk. Szükségünk lesz egy cso- 
portra (például AllUsers), amelyiknek minden érintett fel- 
használó a tagja. Ebben a csoportban az összes program- 
futtatásra vonatkozó beállítást le kell tiltanunk. 

Ezen túlmenően a csoportok sorrendjében ennek a csoport- 
nak kell a leghátul állnia. Így, ha egy felhasználót kive- 
szünk például a Calculator csoportból, akkor csak egyetlen 
olyan csoportnak (AllUsers) lesz tagja, ahol a Calculator je- 
lölőnégyzete nem szürke. Így a házirend végrehajtása so- 
rán a beállítás letiltása lép életbe, vagyis a programhoz 
tartozó bejegyzés kitörlődik a regisztrációs adatbázisból. 





43 Allusers Properties 


Podlicies ] 
















Al ser 
WD Programok futtatása 
(D Notepad 


5 
Group Priority EGZ XX] 


Arange the groups in order of priority. 


Groups highest on the list have the highest priority. If a user belong: to 
9roups that have different settings for the same policy, the setting for the 
9roup with the highest priority takes precedence. 


Group Order: 







Notepad 
(EB Calculator 


CEH 









OK Cancel 
ELTE 


Végezetül fontos megjegyezni: a gyakorlati tapasztalatok 
azt mutatják, hogy csak akkor működik jól ez az átalakítás, 
ha a beállításokat egy újonnan létrehozott ntconfig.pol 
fájlba mentjük el. 


Tomasz Balázs, 
balazs.tomaszohu.hypovereinsbank.com 
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Network Monitor 


Mire e cikk megjelenik, a karácsony már a múlté lesz. Min- 
denki lázasan püföli munkahelyén a billentyűket, és lassan 
ismét elfelejti milyen is az élet számítógépek nélkül. Pedig 
a karácsony sokunk számára a billentyűzet elengedésének 
ünnepe is egyben! Ha pedig az emberre rátör a kóros billen- 
tyűzhetnék, akkor sem jut hozzá, hisz - ugyebár - számító- 
gép nincs otthon. Rajtam valami olyan elemi erővel lett úr- 
rá a billentyűzhetnék, hogy kénytelen voltam kicsomagolni 
azt a hazahozott laptopot, amit suttyomban pont azért 
csempésztem haza, hogy ha jelentkeznek az elvonási tüne- 
tek, ne kelljen orvoshoz fordulnom. Így esett, hogy szent 
karácsony harmadik napján feladtam a küzdelmet, és a 
hosszú elvonókúra után elkékült arccal, remegő inakkal bil- 
lentyűzetet ragadtam, hogy megírjam ezt a cikket a Network 
Monitorról, mely önmaga is egy narkó. Mármint a NetMon. 
Nem hagyja az embert békében pihenni, keretekkel és cso- 
magokkal tömi meg a gyanútlan áldozat fejét, aki a világot 
is üzenetszórásos csatornának látja, és maximum 1514 báj- 
tos csomagokban hajlandó felvinni az emeletre a karácsonyi 
bevásárlás súlyos, ám - csakúgy mint az Ethernet kártya szá- 
mára - értelmetlen terhét. 


Megfejtés 

A múlt hónapban egy rejtvénnyel fejeztem be a cikk első ré- 
szét, mely így hangzott: mi a PING által szállított , hasznos" 
adat? Azoknak helyes a megfejtése, akik az angol ABC betűit 
találták meg a , number of data bytes remaining" szekcióban. 










: Packet Type - Echo 
Echo Code z 0 (0x0) 

: Checksum 2 OxX3ASC 

: Identifier 5 512 (Ox200) 
Seguence Number s 4352 (O0xL100) 







0x0020) 





00 AO CC CO 71 18 00 20 18 Al B9 DZ 08 00 45 00 
00 3C E4 5A 00 00 80 01 FE 41 AC 10 00 01 AC 10 
00 03 08 00 3A SC 02 00 11 00 

















o A PING , hasznos" terhe 


Ez alapértelmezésben 32 bájtnyi ABC. Ha a PING parancsot 
-I kapcsolóval indítjuk, sokkal precízebben meg tudjuk ad- 
ni, hogy mennyi legyen a hasznos teher. Minimális értéke 
1, maximuma 65500. Az jó sok. Hallottak már a halálos 
PING-ről? Régi tréfa, korábbi operációs rendszerek elleni 
méreg. Hogyan is működik a PING? A kezdeményező gép el- 
küld egy bájtsorozatot a célgépnek (ECHO), amelyik ezt hi- 
bátlanul megismételve visszaküldi (ECHO REPLY). Ahhoz, 
hogy meg tudja ismételni, a beérkező , hasznos" adatokat 
rögzítenie kell, el kell tárolnia a memóriában. Tipikus biz- 
tonsági rés, amikor egy protokoll megvalósításánál a prog- 
ramozó nem kezeli le az összes előforduló esetet, csak azo- 
kat, amelyeket a szabványban is leírtak - vagy még azokat 
sem. Nos, a korai ICMP ECHO-k szinte mindegyike ,megva- 
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lósította" ezt a hibát, még a büszke Linuxok is. Valahogy 
úgy kell elképzelni, hogy a programozó lefoglalt az ECHO 
számára egy meghatározott méretű puffert (mondjuk 10000 
bájtot, az nem olyan sok) és ezzel a dolog el is van intéz- 
ve. Szépen működik is a pingecske mindaddig, amíg a 
shasznos" teher meg nem haladja a lefoglalt puffer mére- 
tét. De amint túllépi a bűvös határt, a többletkarakterek 
már nem a lefoglalt pufferbe kerülnek, hanem valamilyen 
más memóriaterületre - ami a kernel mód szabályai szerint 
akármi is lehetett. De messzire elkalandoztam (hiába, ez az 
ünnepek hatása) a halálos PING már nem létezik! Már csak 
a legbénább hackerek próbálkoznak vele, de azokat is meg- 
fogja minden tűzfal, beleértve az ISA Servert is. 


PING 

Hanem vizsgáljuk meg a PING forgalmát tetőtől talpig, hisz 
egy csomó olyan dolgot tartalmaz ez a néhány csomag, ami 
minden hibakeresést megkönnyíthet. 


Terminológia I. 

Cikkemben teljesen vegyesen használom a hálózatról elka- 
pott adatokra a keret és csomag szavakat. Valójában min- 
dig ugyanarról beszélek. A megkülönböztetés szőrszálha- 
sogatás esetén fontos lehet, de itt nem ezzel foglalko- 
zunk. Történelmi okokból ugyanis ugyanazt az adathal- 
mazt más-más névvel illetjük a rétegzett hálózati archi- 
tektúra különböző szintjein: 

Ehternet szinten keretről beszélünk (frame) 

IP szinten csomagról (datagram) 

TCP szinten pedig szegmensről (segment) 

De én már csak maradok az összevissza keverésnél,.. 


Felmerülhet a kérdés, hogy vajon miért e körül a 8-10, vi- 
szonylag egyszerű csomag körül ólálkodunk, miért nem ug- 
runk bele valami kőkeménybe, például az NTLM hálózati for- 
galmába? Azért, mert ez a néhány csomag olyan, mint ci- 
garettahamu a gyilkosság helyszínén: Sherlock Holmes nem 
rohan el ilyen fontos bizonyíték mellett anélkül, hogy meg 
ne vizsgálná, és következtetéseket vonna le! Ebben a pár 
bájtban választ kapunk az élet néhány alapvető kérdésére 
is: vajon miért nem a www.microsoft.com gép MAC Addres- 
se található a feladott Ethernet csomagban, amikor oda- 
böngészünk? A hamu megtalálható lapunk webhelyén a ja- 
nuári előzetesről szóló lapon, neve PING.CAP, és akármelyik 
telepített NetMonnal megnyitva minden kedves olvasó pon- 
tosan ugyanazokat a kereteket, méreteket és sorszámokat 
láthatja, mint ami itt a cikkben is látható. 
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ARP, ARP, ARP 
Kezdjük az ARP-pal, ezzel a kérdezz-felelekkel: 





2 1.752293  CIS TEALB9DZ "BROADCAST ARP RARP 
ARP: Reguest, Target IP: 172.16.0.3 
3 1.75Z293 — LOCAL CIS TEALIB9DZ ARP RARP 


ARP: Reply, Target IP: 172.16.0.1 Target Hd.j 











0 ARP kérés és válasz 


Ami magyarul így hangzana: 
- Fiúk, melyikőtöknek az IP címe 172.16.0.3? 
- Az enyém! Itt a MAC Addressem! 


Itt leolvasható, hogy a kérés a CIS TE-A1B9D2-ként azono- 
sított hálózati kártyáról indul ki, és broadcast címzést hasz- 
nál, és a 172.16.0.3 IP című gépet keressük a magyar ha- 
tárban. Ebből következik, hogy e kérést az összes, ezen a 
szegmensen található gép értelmezni fogja, és a kérést fel- 
dobja operációs rendszerének, hogy a magasabb intelligen- 
cia válaszolhassa meg a kérdést: az IP cím az adott gépé- 
e. Erre az én gépem (LOCAL) válaszol, mivel övé a keresett 
IP cím, de már nem broadcasttal, mert a kérésből kiássa a 
feladó MAC Addressét, és közvetlenül annak válaszol. 
Kevesen tudják, hogy az ARP tetszőleges hardvercímet (te- 
hát nemcsak Ethernet, hanem egyéb címeket is) fordít tet- 
szőleges ,magasabb" címre. Erre ékes bizonyíték az ARP 
csomag belsejében található: 


ARP RARP: Hardware Type 5 Ethernet (10Mb) 

ARP RARP: Protocol Type - 2048 (0x800) 

ARP RARP: Hardware Address Length - 6 (0x6) 

ARP RARP: Protocol Address Length -— 4 (0x4) 

ARP RARP: Opcode - Reguest 

ARP RARP: Sender"s Hardware Address - O0O2O18A1B9D2 
ARP RARP: Sender"s Protocol Address - 172.16.0.1 
ARP RARP: Target"s Hardware Address 5 000000000000 
ARP RARP: Target"s Protocol Address - 172.16.0.3 


A kétbájtos Hardware Type mező mutatja, hogy itt a 10 me- 
gabites Ethernet bizony csak egy aleset, egy a sok létező 
fizikai réteg közül, melynek fizikai címei éppenséggel hat 
bájtosak (Hardware Address Length - 6). Ennél is érdekfe- 
szítőbb ugyanakkor, hogy az IP is csak egy az ARP által tá- 
mogatott sok protokoll közül - melynek négy bájtosak a cí- 
mei (Protocol Address Length - 4). Ugyanez az ARP változ- 
tatás nélkül ki tudná szolgálni az Ipv6-ot Token Ringen! 
Az Opcode - Reguest jelzi, hogy ez egy ARP kérdés, ennek 
párja az Opcode - Reply a következő csomagban. 

S ezután következik a feladó hardver- és protokollcíme 
(MAC Address és IP cím), majd a kérdéses gép hardvercíme 
üresen marad (hisz fogalmunk sincs, erre irányul a kérdés) , 
s végül a célgép IP címe olvasható. 

Kristálytiszta? 

Nem tűnnek fel a kakukktojások? 


1. kakukktojás 

Mivégre szerepel a feladó saját MAC Addresse az ARP ké- 
résben, hiszen ugyanez az adat az Ethernet keretben is 
szerepelt? Minek küldi át a CIS TE-A1B9D2 kétszer ezt az 
adatot? Lehetséges válaszok: 
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A) Mert az ARP protokoll írói nem tudhatták előre, hogy 
a fizikai réteg is hordozni fogja ugyanezt az adatot. 
Emiatt a költségesebb, de előrelátóbb megismétlés 
mellett döntöttek. 

B) Mert bár ott van a MAC Address az Ethernet keretben, 
az a célgép , agyáig" nem jut el, mert a rétegzett há- 
lózati architektúrának megfelelően minden magasabb 
szintű réteg csak az alatta lévő réteg által cipelt ada- 
tot kapja meg (emlékezzünk: , number of data bytes 
remaining"), így az a MAC Address nem jut fel - az 
Ethernet kártya meghajtója éppúgy lefejti és lenyeli, 
mint például a célgép hardvercímét. 

C) Mert az ARP protokollt a Microsoft írta, aki nincs 
jóban a Xerox-szal, aki pedig az Ethernet szabvány ura. 

Ugye milyen csábító az A válasz? Nem-nem! B! 


2. kakukktojás 

És mit keres ott a kérdező MAC Addresse? Kit érdekel? Hisz 

a célgép MAC Addressére kérdezünk! 

A) Azért van ott, mert az ARP után roppant nagy valószí- 
nűséggel kétirányú adatátvitel következik a feladó és a 
cél között, s ez biztosítja, hogy nem csak a kérdező 
fogja megtudni a célgép hardvercímét, hanem a célgép 
is tudomást szerez a kezdeményező címéről - mégpe- 
dig nulla darab hálózati csomag elküldésével. Ez az 
adat ,csak úgy" bejön! 

B) A kérdező MAC Addresse a szimmetria miatt van ott, az 
ARP tervezői művészlelkek voltak, és harmóniára tö- 
rekedtek. 

C) Ez arra szolgál, hogy ha már az IP cím beállításánál 
nem derült ki az esetleges címütközés, akkor majd most, 
ezzel a broadcast csomaggal felszínre kerül. Hisz itt be- 
kiabáljuk a hálózatba saját IP címünket és MAC Addres- 
sünket, mely minden géphez eljut, s ha valamelyik eset- 
leg ugyanezt az IP címet kapta, most észbekaphat. 

No nézzük! A B válasz komplett hülyeség. Az A itt is csábí- 

tó, és igaz is! Erről meggyőződhetünk az ARP gyorsítótárak 

kilistázásával: noha a pingfogadó gépen a kisujjunkat sem 
mozdítottuk, az ARP - a feltárja, hogy a cache bizony gyara- 
podott! És a C? Mi az, hogy egy IP cím ütközés nem derül ki? 

A C válasz helyes, de marad a rejtélyes kérdés: hogyan for- 

dulhat elő, hogy két gépen azonos IP címet állítunk be, és 

az csak percekkel/órákkal később derül ki? 

A megfejtéseket levelezési listáinkon várjuk: 

1. feliratkozás a [1] címre írott üres levéllel 

2. Megfejtés beküldése a [2] címre írott, a megfejtést tar- 
talmazó levéllel. 

Beküldési határidő nincs, ehelyett szorgos feliratkozás 

van. Honnan fogja jó előre megtudni a következő szám 

részletes tartalmát, ha nem iratkozik fel? 

Egyébként lassacskán mindent tudunk az ARP-ról. Talán 

még annyit tennék hozzá, hogy az ARP dolgozik az IP cím 

ütközések azonnali kiderítésénél (ami NEM a rejtvény tár- 
gya!) oly módon, hogy minden gép, amelyik új IP címet 
kap, ,megarpolja" azt mielőtt véglegesítené. Ilyenkor az 

ARP így hangzik: E 

- Fiúk, melyikőtöknek az IP címe az én jövendőbeli IP cí- 

mem? 

S ha erre jön válasz, akkor a cím foglalt. Ezt az ARP-ot Gra- 

tious ARP-nak hívják, és ezen kívül még egy szerepe van: 

mivel a fenti kiáltás broadcast, minden géphez eljut, és így 
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minden gép kijavíthatja az ARP gyorsítótárába esetleg be- 
szorult korábbi értékeket. Az ARP tehát a Microsoft Cluster 
Server működésének alapja. A következtetés talán egy ki- 
csit hirtelennek tűnik, de így van, ARP nélkül nincs fürtö- 
zés. Itt és most nem fejtem ki részletesebben, mert koráb- 
ban, más újság hasábjain már megtettem. 


IP 
S most térjünk át a következő néhány csomagra, a PING ér- 
demi részére! A harmadik keret tartalma a következő: 


$Frame: Base frame properties 
TPETHEI 0800 


hő 





Ethernetben IP-ben ICMP. Az Ethernet réteget ismertnek ve- 
szem, abban ugyanis továbbra sincsen más, mint a feladó és a 
célgép hardvercíme és a Frame Type, mely megmutatja, hogy 
az Ethernetben IP utazik (0x800). Az IP így néz ki részletesen: 


IP: Version — 4 (0x4) 
IP: Header Length -— 20 (0x14) 
IP: Precedence - Routine 
IP: Type of Service - Normal Service 
IP: Total Length - 60 (0x3C) 
IP: Identification - 58458 (OxE45A) 
IP: Flags Summary - 0 (0x0) 
IP: svseses 0 5 Last fragment in datagram 
IP: ......0. s May fragment datagram if 
A necessary 
IP: Fragment Offset - 0 (0x0) bytes 
IP: Time to Live -— 128 (0x80) 
IP: Protocol - ICMP - Internet Control Message 
IP: Checksum 5 OxFE4l 
IP: Source Address - 172.16.0.1 
IP: Destination Address - 172.16.0.3 
IP: Data: Number of data bytes remaining - 40 
4 (0x0028) 


A legelső bájt az IP verziószámát (felső 4 bit) és az IP fejléc 
hosszát (alsó 4 bit) adja meg. A verziószám azért áll legelöl, 
mert ez alapján derül ki, hogy a többi mezőt hogyan kell ér- 
telmezni. Ennél kisebb verziószámmal nem találkozunk, de 
nagyobbal se. A négyest egyébként nem az ötös követi, ha- 
nem a hatos, ha elterjed. A következő bájt a Type of Service 
és Precedence értékeket hordozza. Ennek a bájtnak a 3-5. 
bitjei a csomag által igényelt késleltetés (delay), megbízha- 
tóság (reliability) és átbocsájtóképesség (throughput). 

A Total Length az IP és az által hordott hasznos adat teljes 
összege bájtokban, azaz 


Total Length- Header Lengtht Number of data bytes 


remaining 


Az Identification egy eléggé kifinomulatlan eljárás az ide- 
oda küldött IP csomagok helyes sorrendjének meghatározá- 
sára. Ne tévedjünk, ez a növekvő sorszám NEM tesz lehető- 
vé hibajavítást azon a szinten, ahogyan majd a TCP dolgo- 
zik, sokkal inkább a töredezett IP csomagok összeállításá- 
ban segédkezik. A következő két bájt (Flags Summary és 
Fragment Offset) a csomag töredezettségével foglalkozik. A 
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mi csomagunk nem töredezett, hurrá. Ezért most ne is fog- 
lalkozzunk ezzel részletesen. 


Time to Live 

Annál fontosabb viszont a TTL (Time to Live) érték. Feltéte- 
lezve, hogy minden olvasóm enyhén jártas az IP útválasztás 
alaptudományában, minden különösebb magyarázat nélkül 
tekintsük meg az alábbi hálózatot, ahol R1, R2 és R3 útvá- 
lasztók (routerek) úgy vannak beállítva, hogy a nyílhegy fe- 
lé mutat az alapértelmezett útvonaluk (Default Gateway): 


"A 
PC 
SZORA a 
i v 
R3 éR2 





Legyen továbbá egy PC-nk (Default Gateway-Router1), 
amelyről megpingetünk egy olyan címet, amihez még csak 
hasonló sincs ebben a hálózatban. Mit tesz R1 az ismeretlen 
című csomaggal? R2-nek továbbítja. R2 ugyanígy tanácsta- 
lan, ezért R3-nak küldi, aki szintén nem áll a helyzet magas- 
latán, ezért átdobja R1-nek. S a kör bezárult. Vajon meddig 
keringene egy hibás csomag ebben a hálózatban? Úgy van, 
a végtelenségig - hacsak...! Ha csak észre nem vesszük, 
hogy kering, és ki nem vesszük a hálózatból. Erre való a TTL. 
Az eredeti szabvány szerint a csomag maximális élettarta- 
mát adja meg másodpercben. A mai routerek azonban x-szer 
gyorsabban dolgoznak elődeiknél, így a legújabb RFC szerint 
a TTL nem másodpercben értendő, hanem ennyi darab útvá- 
lasztón juthat át a csomag. Minden router eggyel csökkenti 
a rajta áthaladó csomagok TTL-jét, és ha ennek értéke eléri 
a nullát, akkor a csomagnak vége. Intelligensebb útválasz- 
tók ilyenkor visszaszólnak az eredeti feladónak egy ICMP Ti- 
me Exceeded üzenettel, hogy értesüljön a katasztrófáról, és 
újra tudjon próbálkozni - most már megnövelt TTL-lel. 


Protocol 

A következő bájt a Protocol mező. Ez határozza meg, hogy 
az IP mit cipel. A 0x1 jelentése: ICMP. Itt álljunk meg egy 
szóra. Megfigyelhető, hogy az IP tudja, mit cipel, miközben 
korábban arról volt szó, hogy számára értelmezetlen a ben- 
ne található adat. Nem szabad összetéveszteni az adatértel- 
mezést a továbbítást segítő Protocol mező szerepével. Az 
IP nem azt tudja, hogy PING-et visz a hátán, hanem azt, 
hogy az általa hordozott adatot a 0x1 azonosítószámú ma- 
gasabb rétegnek kell továbbadnia - s ez valóban az ICMP. 
E mező feladata tehát a bejövő csomag útvonalának deter- 
minisztikussá tétele, hogy ne kelljen találgatni, hogy ami 
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beérkezett, az ízlik-e az ICMP-nek, vagy nem, esetleg a TCP 
fogyasztja majd el, vagy a GRE. Bele van hát írva, hogy ho- 
va kell továbbdobni. Ugyanez az elv lejjebb és feljebb is 
megfigyelhető. Lejjebb, az Ethernet szintjén a Frame Type 
mező szolgált ugyanerre a célra, hogy ne kelljen találgat- 
ni, hogy vajon a beérkezett keret IPX, vagy NetBEUI. Fel- 
jebb, a TCP szintjén a portszámok osztályoznak. 80-as? 
WWW! 25-ös? SMTP! 110-es? POP3! 


Terminológia II. 

Ahogy a csomag elnevezése is változik rétegről rétegre, 
ugyanígy az osztályozást segítő mező neve is. 
Történelmi okokból ugyanis ugyanazt a mezőt más-más 
névvel illetjük a rétegzett hálózati architektúra különbö- 
ző szintjein: 

Ehternet szinten kerettípusról beszélünk (frame type) 
IP szinten protokollról (Protocol mező) 

TCP szinten pedig portról 

Ezt sajnos nem keverhetem össze-vissza, mert a kifeje- 
zések (különösen a port) hétköznapi szavakká váltak 
nyelvünkben... 


Checksum 

Nini, itt is egy CRC! Az Ethernetnek is volt egy! Az igaz, 

hogy, azt nem látjuk a NetMonnal, mert ha az alsó CRC 

rossz, a keret nem jut elénk. De akkor minek még egy el- 

lenőrzőösszeg? Azért, mert egyáltalán nem biztos, hogy az 

IP csomag CRC-vel védett keretben utazik, s biztos ami biz- 

tos, itt is van egy, hogy a szoftveresek is örülhessenek. 

Igen ám, de van itt egy kis baj, kalamajka. 

0 Amikor egy IP csomag áthalad egy útválasztón, csök- 
ken a TTL. 

"I Ha csökken a TTL, elromlik az ellenőrzőösszeg. 

0 Ha elromlik az ellenőrzőösszeg, hibássá válik a csomag. 

Ez nem történhet meg! 

Az útválasztók fontos feladata, hogy a TTL csökkentése 

után újraszámítsák a CRC-t, és hibátlan IP csomagot küld- 

jenek tovább. 


IP címek 

És végül az IP fejlécben olvasható a feladó és a célgép IP 

címe. A célgép címe az odaút kiválasztásához kell, a 

feladóé pedig a visszaút meghatározásában játszik majd 

szerepet. E két cím az, mely végponttól végpontig végigkí- 
séri a csomagot hosszú útján - hacsak proxy vagy tűzfal 
nem állja útját, amely galád módon átirkálhatja mindket- 
tőt. Ezek a címek utazzák végig a teljes útvonalat, ellentét- 
ben a MAC Addressel, mely csak egy adott szegmensen él. 

Az Ethernet rétegbéli MAC Address értelemszerűen nem le- 

het a nagyon távoli (például www. microsoft.com) gép kár- 

tyájának a címe, hisz 

1. semmi garancia nincs arra, hogy a célgép egyáltalán 
Etherneten van. Lehet telefonvonalon, műholdon, mik- 
rohullámon, infrán, telepátián és BlueToothon. 

2. Az Ethernet réteg feladata NEM a végcél, hanem a ki- 
járat megcímzése, azaz messzire menő csomagoknál a tő- 
lem elindított Ethernet keretben a Default Gateway MAC 
Addresse, míg IP fejlécében a távoli gép IP címe szerepel! 
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ICMP 


ICMP: Packet Type - Echo 

ICMP: Echo Code - 0 (0x0) 

ICMP: Checksum -— Ox3A5C 

ICMP: Identifier - 512 (0x200) 

ICMP: Seguence Number - 4352 (0x1100) 

ICMP: Data: Number of data bytes remaining - 32 
4 (0x0020) 


A Packet Type mutatja meg, hogy a negyedik keret egy kér- 
dés (ECHO-Ox08), az ötödik pedig válasz (ECHO REPLY-0). 
Jön még egy checksum. A TCP/IP üldözési mániában szenved. 
A Seguence Number minden kibocsátott ECHO-nál egyedi 
érték, amit a válaszban (ECHO REPLY) meg kell ismételnie 
a felelőnek, hogy a kérdező oldalán egyértelműen meg le- 
hessen állapítani, hogy melyik csomag érkezett vissza. Ez 
ahhoz szükséges, hogy a PING ki tudja számolni a csoma- 
gok megfordulási idejét. Tulajdonképpen a PING igen kor- 
látozott módon ugyan, de sávszélesség-mérésre is alkal- 
mas. Jártam már úgy, hogy egy bérelt vonalról meg kellett 
mondanom az abban lévő ,maradék" sávszélességet, s 
mindehhez a nagy semmi állt rendelkezésemre. Ilyenkor jól 
jöhet egy kis furfang! Küldjünk át a mérendő vonalon ak- 
kora pingeket, hogy az valami mérhető megfordulási időt 
okozzon (a lokális hálózatokon alapban , mérhető" 210 ms 
megfordulási idő valójában mérhetetlenül gyorsat jelent). 
Például: 
PING —-1 10000 ww.internetszolgaltato.hu 
Ha a vonal mondjuk 128 kilobites, akkor körülbelül és dur- 
ván (128/8-)16 kilobájt átvitele egy másodperc alatti-kö- 
rüli válaszidőt kellene adnia, s ha ettől jelentősen eltér ak- 
kor meg tudjuk becsülni, hogy mennyi is a rendelkezésünk- 
re álló sávszélesség. 
Fóti Marcell 
marcellf onetacademia.net 
MCT, MCSE5-I, MCDBA, MZ/X 


eset Et UT 
[1] tech.net-join Olyris.netacademia.net 
[2] tech.neteolyris.netacademia.net 
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Tárolási 
megoldások az 


4/ Exchange 2000 Server-hez 


Az Exchange 2000 adattárolóinak kialakításakor három fő 
szempontot kell figyelembe venni: tárolókapacitás, rendel- 
kezésre állás és teljesítmény. A tárolási megoldás tervezé- 
sekor és kivitelezésekor hozott döntések nagyban befolyá- 
solják az Exchange 2000 felügyeletével és karbantartásával 
kapcsolatos költségeket. 

Az Exchange 2000 tárterületigénye nagyjából megegyezik a 
postafiókok számának és a postafiókonként szükséges tár- 
terület szorzatával. Ha nyilvános mappákat is akarunk hasz- 
nálni, természetesen hozzá kell adnunk ehhez a számhoz az 
ezek tárolásához szükséges tárterület nagyságát. 

A levelezőrendszerre fordított erőforrások és pénz mennyi- 
sége a vállalat igényeitől függ (vannak olyan cégek, melyek 
kis mennyiségű elektronikus levelezést folytatnak, és nem is 
tartják az elektronikus levelezést létfontosságúnak, de ma 
már a cégek többségénél az elektronikus levelezés nélkülöz- 
hetetlen) , és ez jelentősen befolyásolja az üzembehelyezett 
megoldás megbízhatóságát és rendelkezésre állását. A ren- 
delkezésre állás redundáns egységek üzembehelyezésével 
fokozható. A processzorok redundánssá tétele a kiszolgálók 
fürtözésével, az adatok redundanciája pedig RAID megoldá- 
sok üzembehelyezésével érhető el. 

A teljesítmény iránti igény vállalatonként változó (ebben a 
cikkben a teljesítmény alatt az adatátvitel sebességét értjük) . 
Az adatátviteli teljesítményt általában a tárolóeszköz és a 
hozzá kapcsolódó szoftver által másodpercenként végrehaj- 
tott írási és olvasási műveletek számával határozzuk meg. 

Az Exchange 2000 tárolási megoldásának tervezése előtt meg 
kell állapítanunk, hogy cégünk milyen fontossági sorrendet ál- 
lít fel a három fő szempont között, itt főleg a rendelkezésre ál- 
lás és a teljesítmény közti egyensúly megteremtése fontos. 
Ebben a cikkben az Exchange 2000 postafiókjainak tárolásá- 
ra alkalmas tárolók tervezésének alapelveit vizsgáljuk. Nem 
foglalkozunk sem a gyakorlati megvalósítással, sem a fürtö- 
zött megoldások tárolóinak kialakításával, sem a nyilvános 
mappák tárolásával, de természetesen a cikkben vázolt elvek 
felhasználhatók ilyen megoldások kialakításakor is. 


A tárolási eljárások áttekintése 

Az Exchange 2000 telepítésekor alapértelmezésben minden 

adat azon a meghajtón lesz tárolva, melyre magát az alkal- 

mazást telepítettük. Az ilyen, alapértelmezett beállítások- 

kal telepített rendszer teljesítményét, rendelkezésre állását 

és tárolókapacitását az alábbi tényezők határozzák meg: 

"0 A processzorok száma és sebessége 

0 ArKkiszolgáló feladata (például postafiókok tárolása, 
connector (kapcsolódást biztosító) kiszolgáló) 

"8 A merevlemezek száma 

Az Exchange 2000 tárolási megoldásának tervezésekor a 

következőkre figyeljünk: 

"2 A CPU terhelése csökkenthető RAID tömbök, vagy SAN- 
ok (storage area network - tárolóhálózat) kialakításával. 
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-£ Több kisebb merevlemez jobb teljesítményt nyújt, mint 
egy nagy. Például, ha 4 darab 9 GB-os merevlemezt al- 
kalmazunk egy darab 36 GB-os helyett, a tárolótömb tí- 
pusától függően akár négyszeres írási és olvasási sebes- 
séget is elérhetünk. 

"8 Az Exchange nem ugyanúgy kezeli az összes tárolt ada- 
tát, ezért nem az a leghatékonyabb, ha az összes adat- 
típushoz egyféle tárolási megoldást alkalmazunk. 

"8 Azoknál a kiszolgálóknál, melyek nem postafiókok vagy 
nyilvános mappák tárolására szolgálnak (például a con- 
nector kiszolgálók), nem érdemes költséges tárolási 
megoldásokat használni, mert ezek általában csak rövid 
ideig tárolják az adatokat, majd továbbítják őket egy 
másik kiszolgálónak. Nagyon nagy teljesítményigény 
esetén esetleg indokolt lehet ezeken a kiszolgálókon a 
RAID-O alkalmazása. 

Az Exchange 2000 tárolási megoldás tárolókapacitásának, 

teljesítményének és rendelkezésreállásának növeléséhez 

RAID vagy SAN megoldásokat, esetenként pedig ezek 

mindegyikét kell használnunk. 


RAID megoldások 

Bár sokféle RAID megvalósítás létezik, van két dolog, ami 
mindegyikben közös. Mindegyiknél több merevlemezt hasz- 
nálunk, melyeken eloszlanak az adatok, és mindegyiknél 
valamilyen rendszer szerint tároljuk az adatokat, ami az 
adatokat tároló alkalmazástól független. 

Ebben a cikkben a három fő RAID típust (és az egyik altí- 
pust) ismertetjük: a RAID-O-t, a RAID-1-et (és annak 0--1 
altípusát) és a RAID-5-öt. Bár sokféle RAID megoldás léte- 
zik, ezek valamilyen formában a fenti három fő típus kom- 
binálásával hozhatók létre, ezért ezeket nem ismertetjük. 


RAID-O 

A RAID-O egy merevlemeztömb, amin egy csíkkészlet van 
kialakítva. Minden lemez úgy van particionálva, hogy a csík 
végigfut a tömb összes merevlemezén, így azok egyetlen lo- 
gikai partícióként jelennek meg. Egy RAID-O-t használó al- 
kalmazás például a D: meghajtóra menti az adatokat, míg a 
tömb elosztja azokat a merevlemezmeghajtók között. Az 1. 
ábrán látható RAID-O tömb például négy merevlemez között 
osztja el az adatokat. 
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0 RAID-O merevlemez tömb 
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Teljesítmény szempontjából a RAID-O a legjobb RAID 
megoldás, mivel (példánk szerint) egyszerre négy lemezt 
használhat az írási és olvasási műveletek végrehajtásakor, 
ami a merevlemezek leghatékonyabb használatát jelenti. 

A RAID-O egyetlen hibája az, hogy valójában nem is RAID :), 
hiszen nem redundáns, és éppen ezért nem megbízható. Ha 
az Exchange postafiókadatbázisait egy RAID-O tömbön tárol- 
nánk (ne tegyük!), egyetlen merevlemez meghibásodása 
esetén az összes postafiókadatbázist vissza kell állítanunk a 
működőképessé tett RAID-O tömbre, és vissza kell állítanunk 
a tranzakciók naplófájljait. Ha pedig a tranzakciók naplófájl- 
jait is ezen a tömbön tároltuk, akkor csak az utolsó mentés- 
ben meglévő postafiókadatbázisokat tudjuk visszaállítani. 


RAID-1 (és 0-1) 

A RAID-1 két tükrözött merevlemezből álló tömb. Ha több 
mint két lemezt akarunk használni, a lemezek csíkkészletek- 
be vannak rendezve, és a csíkkészletek vannak tükrözve, így 
a tömb minden merevlemeze meg van kettőzve. Ez a RAID- 
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merevlemezeinek száma), vagyis a RAID-5 megoldásnál, 
egy darab lemezt fel kell , áldoznunk". Hat darab 9 GB-os 
merevlemezből tehát 45 GB hasznosítható tárterületünk 
lesz. A paritás fenntartásához egy alkalmazás írási művele- 
te két írási, és két olvasási műveletet jelent a RAID-5 
tömbben, így csökken a teljesítmény. 

A RAID-5 megoldás előnye az, hogy megbízható, és a 
RAID-1-nél (vagy a 0--1-nél) hatékonyabban használja ki a 
rendelkezésre álló merevlemezeket. 


A RAID megoldások összehasonlítása 

Mivel a szükséges tárolókapacitás általában adott, a RAID 

megoldások költségeit, teljesítményét és a megbízhatósá- 

gát fogjuk összehasonlítani. A következő táblázatunk ké- 

szítésekor az alábbiakat feltételeztük: 

"I 90 GB adatot kell tárolnunk. 

-2 9 GB-os merevlemezeket használhatunk. 

- A merevlemezeink 100 I/O műveletet képesek elvégez- 
ni másodpercenként 


Olvasási műveletek 
maximális száma 


Írási műveletek 
maximális száma 


04-11. Egy RAID-0--1 tömbben az összes lemez tárolókapaci- Eszközök 


tásának felét használhatjuk ki. Írási műveletkor ugyanaz az RAID száma Megbízhatóság 






































adat fog a lemezre, és a lemez tükrözött párjára kerülni. megoldás  ( (költség) ( másodpercenként ( másodpercenként 
RAID-O 10 1000 1000 Nem megbízható 
RAID-0--1 20 1000 2000 Nagyon jó 
RAID-5 11 275 1100 Jó 
5 A RAID megoldások összehasonlítása 
a RAID-1 merevlemez tömb A RAID-1-nél csak két merevlemez használható, ezért nincs 
feltüntetve a táblázatban. 
A RAID-1 (vagy a 0-1) a legmegbízhatóbb a háromféle A megbízhatóságot azzal mérjük, hogy egy merevlemez 
RAID tömb közül, hiszen az adatok íráskor tükrözve van- meghibásodása milyen hatással van az adatok sértetlensé- 
nak. Az összes merevlemez tárterületnek csak a fele hasz-  gére. A RAID-O-ban nincs redundancia, így egyetlen merev- 
nálható, ezért úgy tűnhet, hogy a RAID 1 (vagy 05-11) nem lemez meghibásodása is az összes adat elvesztését jelenti. 
hatékony megoldás, mégis ezt használjuk, ha a lehető leg- . A RAID-0--1 a legmegbízhatóbb megoldás, mert legalább 
nagyobb adatbiztonságot akarjuk elérni. két merevlemeznek el kell romlania ahhoz, hogy adatvesz- 
tés következzen be. Ez is nagyon egyedi eset lenne, mert a 
RAID-5 csíkkészletekben egymásnak megfelelő lemezeknek kellene 
A RAID-5 - a RAID-0-hoz hasonlóan - egy olyan merevle- ugyanakkor meghibásodniuk. A táblázatunkban feltüntetett 
mez tömb, melyen egy csíkkészlet van kialakítva, de a — megoldás akár tíz merevlemez (az egyik teljes csíkkészlet) 
RAID-5 tartalmaz paritást is. Ez azt jelenti, hogy a RAID-5 egyidejű meghibásodását is elviseli. A RAID-5 megoldás is 
tömbben működik egy olyan mechanizmus, mely biztosítja megfelelő megbízhatóságú, de ennél bármely két lemez 
a tömbben tárolt adatok sértetlenségét. Egy merevlemez egyidejű meghibásodása adatvesztést eredményez. 
meghibásodása esetén az adatok helyreállíthatók a meg- A költséget a tömb kialakításához szükséges merevlemezek 
maradt lemezekről, ezért a RAID-5-öt megbízható tárolási számával mérjük. A RAID-0--1 megoldás a legköltségesebb. 
megoldásnak tekintjük. Ennél a szükséges tárterület kétszeresét kell megvásárol- 
nunk, de teljesítménye is 
RAID 5 geeeeeeeesssséei seresesseezesesesessssééeg lényegesen nagyobb; mint 
: B: :Block D: Block EiBlock ét ús 
i az azonos tárolókapacitású 
i 6) a e. S RAID-5 megoldásé. 
Lessese] e... S A S S 4 
iD KB Lc1g a Paris] VET SAN megoldások 
Generation KB2 eper JDZ A EZT A SAN-ok. (storage area net- 
(arat LBJ LD3/ WE3 4 work - tárolóhálózat) tárolá- 
B c D4 E4 si lehetőségeket és azok 
felügyeletét biztosítják. A 
0 RAID-5 merevlemez tömb SAN-ok úgynevezett Fibre Channel switching (kapcsolt, 
üvegszálas hálózati) megoldásokat biztosítanak az alkal- 
A paritás fenntartásához minden egyes gigabájtnyi tároló-  mazások, és az általuk használt tárolók közti gyors és meg- 
területünkből fel kell áldoznunk 1/n GB-ot (az n a tömb bízható kapcsolatok megvalósításához. 
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Egy SAN három fő összetevőből épül fel: 

"0 Fibre Channel switching megoldás 

- Tárolórendszer 

"0 Tároló és SAN felügyeleti szoftver 

A hardvergyártók általában teljes SAN csomagokat adnak el, 
melyek tartalmazzák a szükséges hardvert, szoftvert és a tá- 
mogatási szolgáltatásokat. A SAN szoftver felügyeli a háló- 
zatot, és megvalósítja az adatátvitel redundanciáját azzal, 
hogy a tárolt adatokhoz több elérési utat biztosít. A SAN- 
ok lehetővé teszik heterogén rendszerek összekapcsolását, 
akár különböző operációs rendszerek, több gyártótól szár- 
mazó tároló-rendszerekhez való kapcsolását. 





Storage Storage 


Storage 
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Fibre Channels : 
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5 SAN tárolási megoldás 


Jelenleg a SAN-ok jelentik a legjobb megoldást nagy- 
mennyiségű adat biztonságos tárolására. Még a legkisebb 
SAN-ok is képesek 5 terabájtnyi adat tárolására. 

Bár üzembehelyezésük költséges, a hosszú távú teljes bir- 

toklási költség alacsonyabb lehet, mint a több kisebb tömb- 

nél. A SAN megoldások alábbi előnyeit nem lehet figyelmen 
kívül hagyni: 

"1 Ha több tömbünket több rendszergazda felügyeli, a tel- 
jes tárolórendszer központosított felügyelete lehetővé te- 
szi, hogy rendszergazdáink más feladatokat lássanak el. 

"0 A gyártója által támogatott SAN megoldással semmilyen 
más tárolórendszer nem veheti fel a versenyt megbízha- 
tóság területén. Ha vállalatunknak a levelezőrendszer 
(vagy bármely más rendszer) kiesése jelentős veszteséget 
okozna, egy SAN költséghatékony megoldást jelenthet. 

Egy SAN megvásárlása előtt mindenképpen érdemes összeha- 

sonlítani a jelenlegi megoldás kapcsán felmerülő költségeket 

és a SAN költségeit, valamint érdemes felmérni, hogy valójá- 
ban mennyire lenne kihasználható vállalatunkban a SAN. 


Az Exchange adatainak tárolása 

Az Exchange három fő helyen tárol adatokat: 

"b A Simple Mail Transfer Protocol (SMTP) várakozási sor 
könyvtárban 

.edb és .stm fájlokban 

"b Tranzakciók naplófájljaiban 
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Az SMTP várakozási sor könyvtár 

Az SMTP várakozási sor addig tárolja az üzeneteket, amíg 
azok továbbítódnak egy adatbázisba (az üzenet típusától 
függően személyes vagy nyilvános adatbázisba), másik ki- 
szolgálóhoz, vagy connectorhoz. 

Általában az üzenetek rövid ideig vannak az SMTP várako- 
zási sorban, ezért annak tárolási megoldását inkább na- 
gyobb teljesítmény eléréséhez kell igazítani, nem a tároló- 
kapacitáshoz és megbízhatósághoz. Néha - amikor az üze- 
neteket nem lehet továbbítani - az SMTP várakozó sorban 
nagymennyiségű adatot kell tárolni, emiatt a RAID-O csak 
akkor elfogadható tárolási megoldás, ha az üzenetek elve- 
szítése elfogadható. A RAID-1 megfelelő megoldás lehet, 
mert megbízható, és jó adatátviteli teljesítményt biztosít. 


Az .edb és .stm fájlok 

Egy Exchange adatbázis egy rich-text .edb fájlból, és egy 
natív multimédia tartalmú .stm fájlból áll. Az .edb fájl tá- 
rolja az összes MAPI üzenetet, a tárolási folyamat táblákat 
használ az összes üzenet, az edb és stm fájlok ellenőrző 
összegeinek és a MAPI üzenetek elhelyezésére. Az .stm fájl 
natív Internet tartalommal rendelkező üzeneteket tartal- 
maz. Mivel az edb és stm fájlok elérése általában véletlen- 
szerű, elhelyezhetők ugyanazon a tárolón. 

Ezeknek a fájloknak a tárolásához megbízható megoldásra 
van szükség, tehát a RAID-O alkalmazása nem ajánlott. A 
fontossági sorrendben a megbízhatóságot követheti a telje- 
sítmény (RAID-1) , de a tárolókapacitás (RAID-5) optimalizá- 
lása is. Mi inkább a RAID-1 (vagy 0--1) használatát ajánljuk. 
Mivel a nyilvános mappákba általában kevesebbszer írnak, 
mint ahányszor olvassák őket, ezek fájljaihoz jó megoldás 
lehet a RAID-5. 


A tranzakciók naplófájljai 

A tranzakciók naplófájljai nyilvántartják az .edb és .stm fáj- 
lok állapotát, és biztosítják azok sértetlenségét, ami azt je- 
lenti, hogy a naplófájlok jelképezik az adatokat. Minden táro- 
lócsoport rendelkezik saját tranzakciói naplófájljával (adatbá- 
zissal). Ha meghibásodás történik, és újra üzembe kell állíta- 
ni a kiszolgálót, az utolsó tranzakció naplófájlok használha- 
tók az adatbázisok helyreállítására. Ha megvannak a naplófáj- 
lok, és az utolsó biztonsági mentés, az adatok visszaállítha- 
tók, ha a naplófájlok elvesznek, elvesznek az adatok is. 

A meghibásodás utáni visszaállítás mértéke a naplófájlokon 
múlik. A jó megbízhatóság és teljesítmény elérése érdeké- 
ben célszerű minden tárolócsoport naplófájljait külön meg- 
hajtón tárolni. A tranzakciók naplófájljainak tárolóinál a 
megbízhatóság és a teljesítmény a legfontosabb, ezért a 
RAID-1 (vagy 0--1) használata ajánlott. 
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IIS mögött 


A Windows 2000 család szerves részeként az Internet Infor- 
mation Services 5.0-s verziója a 4-es kiadás pozitív hagya- 
tékát erősítendő a lehető legtöbb beállítási információt - a 
korábbi IIS változatokkal ellentétben amelyek teljesen a re- 
gisztrációs adatbázisba dolgoztak - a metabase elnevezésű 
tárolási helyre menti. A szerverek webkiszolgálási szerepé- 
nek előtérbe kerülésével szükségessé vált, hogy a gyakran 
változó, a különböző szerveralkalmazások által kiolvasandó 
és változtatandó IIS beállítási paraméterek ne olyan rela- 
tíve lassú elérésű helyen tárolódjanak, mint a regisztrációs 
adatbázis. A biztonsági kérdések elkülönítve kezelhetőek - 
így elkerülhetőek a regisztrációs adatbázison belüli poten- 
ciális jogosultság-problémák. A metabase azonban ennél is 
több: az IIS alapú webkiszolgálók manuális és automatizált 
rendszeradminisztrációja teljesen rá épül, valamint a szer- 
veroldali webprogramozás finomhangolása és opcionális 
paraméter-tárolása is általa oldható meg. Remélem, hogy 
sikerül sok olyan kérdést is megválaszolnom ebben a cikk- 
ben az IIS-sel kapcsolatban, amelynél gondolni sem mer- 
tünk volna arra, hogy ez a misztikus név mögé rejtőző kon- 
figurációs adatbázis a hunyó. 


Otthon, édes otthon 

A metabase rejtekhelye kezdetben egy állományban talál- 
ható a merevlemezen, majd az IIS szolgáltatások elindulá- 
sakor a memóriába töltődik (a már korában említett sebes- 
ség-okok miatt) . A változtatásokat a masina automatikusan, 
rendszeres időközönként menti a merevlemezre, és az IIS 
szolgáltatások megállásakor is teljesen visszaíródik a fájlba, 
amely alapértelmezésben az alábbi elérési úton található: 


$SystemRoot$Iwinntisystem32YVinetsrviIMetaBase.bin 


Ezt az elhelyezést meg tudjuk változtatni, ha szükséges, er- 
re a regisztrációs adatbázisban a 


LOCAL MACHINEYSOFTWAREMicrosoftlINetMgrN 


4 Parameters 


kulcshoz felvett REG SZ típusú, MetadataFile elnevezésű ér- 
ték felvételével van lehetőségünk, ahol is az adatmezőbe 
az általunk manuálisan áthelyezett metabase állomány új, 
iMnmewmetabase mewmetabase. bin. Védjük a fájlt NTFS jo- 
gosultságokkal, amit ne felejtsünk el a mentések (lásd ké- 
sőbb) által létrehozott tartalékokon is elvégezni! 


A metabase logikai felépítése 

A metabase belső logikai felépítése sokban hasonlít a Win- 
dows család regisztrációs adatbázisainak felépítésére, 
amelyben az alap kiindulási csomópontok (node) alatt hie- 
rarchikus struktúrában kulcsokat és az azokhoz kapcsolódó 
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értékeket találjuk. A kulcsok alatt további alkulcsok talál- 
hatóak, az IIS logikai felépítését tükrözve. Minden egyes 
webkönyvtár rendelkezik egy neki megfelelő kulccsal a me- 
tabase-ben. Az értékeknek 3 fajta adattípusa létezik: 
DWORD, Binary és String; valamint a String típusúnak két 
tesen egy adott kulcs (másnéven metabase tulajdonság) 
csak bizonyos értékeket, és azokon belül bizonyos értéktí- 
pusokat támogathat, behatárolva ezáltal a beállítható ada- 
tokat. A magasabb szinten definiált paraméterek értékeit 
alapértelmezésben öröklik az alacsonyabb szinten találha- 
tóak, azonban van lehetőség egyedi beállításokra is. A me- 
tabase hierarchikus felépítése az IIS elrendezését követi, 
tehát a gyökér web, ftp, smtp szolgáltatások alatt/mellett 
megtaláljuk a virtuális kiszolgálók, könyvtárak és webhe- 
lyek al-csomópontjait. Az egyedi kulcsokra és értékükre a 
teljes metabase elérési úttal (path) hivatkozhatunk, amely- 
ben az egyes szinteket sima per (/) jellel választjuk el. Egy 
példa elérési út tehát így néz ki: W3SVC/1/Root/path, 
amely az alapértelmezett webkiszolgáló gyökérkönyvtárá- 
nak a merevlemezen való elhelyezkedését tárolja. A fő-cso- 
mópontok között az LM a LocalMachine rövidítéseként az 
adott gép egyes szolgáltatásainak (web, smtp) konténere- 
ként szolgál. Az alá tartozó kulcsok közül a W3SVC a web, 
az SMTPSVC pedig az smtp szolgáltatás alapját képezik. Az 
LM-mel egyenrangú fő-csomópontként a Schema a kulcsok 
és értékek összefoglaló katalógusát tartalmazza. 


IIS rendszeradminisztráció 

Elérkeztünk a legérdekesebb kérdéskörhöz: hogyan is tudjuk 
az IIS paramétereit állítani? Hogyan férünk hozzá a ,halan- 
dó" rendszergazdák elől elrejtett értékekhez? A metabase ér- 
tékeinek megtekintésére és módosítására rendszerfelügyeleti 
szempontból sokféle lehetőség is van. Az IIS menedzsment- 
architektúrája teljes mértékben a metabaseben végződik, azaz 
a legalapvetőbb kiindulási pontként minden érték, paraméter 
ide íródik be, és innen olvasódik ki. Tehát az IIS felügyelete 
valójában a metabase tartalmának manipulálásával egyenér- 
tékű. Ez alól kivétel néhány, az inetinfo.exe futtatására vo- 
natkozó globális paraméter, amelyek a regisztrációs adatbázis 
lakói. Az IIS menedzsmentjének két építőkockája az IIS Ad- 
ministration Objects (IIS Admin Objects) és az ADSI. Az 
ADSI-t részletesen tárgyaló cikksorozat a Tech.Netben lehető- 
vé teszi, hogy átugorjam az ADSI általános részletezését. Az 
IIS Admin Objects ADSI szolgáltatóként jelenik meg a klien- 
sek felé, ezáltal a szabványt betartva többféle módon-is meg- 
közelíthető a metabase. Az IIS Base Admin Objectek, amelyek 
DCOM objektumként az IIS Admin Objectek mögött rejtőznek, 
az IIS alap rendszerobjektumaiként közvetlenül kezelhetőek 
az alacsonyabb szintű programnyelvek (pl. C--) által (lásd do- 
kumentálva a [1] címen), így bonyolultabb IIS rendszerkeze- 
lő funkciókat is implementálhatunk egy alkalmazásban. 
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o Az IIS rendszeradminisztrációs architektúrája 


Internet Services Manager 

A legegyszerűbb, legismertebb grafikus felületű menedzs- 
ment-eszköz az IIS-sel feltelepíthető Internet Services Ma- 
nager. Két változata közül a Microsoft Management Conso- 
le (MMC) alapú széles funkcionalitást nyújt, mivel közvet- 
lenül a DCOM objektumokkal dolgozik. A HTML alapú válto- 
zat korlátozott eszközkészletével az ASP oldalakba ágyazott 
scriptekre épül (lásd lejjebb) . Ne feledjük, hogy még az erő- 
teljesebb MMC alapú változatnál is az eredeti metabase hie- 
rarchia csak részben látszódik, valamint hogy a kulcsok va- 
lódi elnevezései, típusai teljes mértékben rejtettek marad- 
nak előlünk. Előnyük, hogy távoli menedzselésre alkalma- 
sak, mivel az MMC változattal akár egy munkaállomásról 
csatlakozhatunk más kiszolgálókhoz, míg a HTML Internet 
Services Manager-t futtató IIS kiszolgálókat egy egyszerű 
(IE 43) böngésző segítségével, az Interneten vagy az int- 
ranetünkön keresztül vezérelhetjük. 
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5 Az Internet Services Manager jól ismert MMC változata 


MetaEdit 

A metabase professzionális szerkesztésére legalkalmasabb 
eszközként a MetaEdit nevű grafikus segédprogram hitele- 
sen jeleníti meg az eredeti hierarchikus struktúrát, vala- 
mint általa módosíthatóvá válik minden érték, amely az In- 
ternet Services Managerben még rejtve maradt. A Windows 
2000 Server Resource Kit CD-n (és a Supplement One kiegé- 
szítőn) található 2.0-s verziónál újabb érhető el a Microsoft 
weboldalán: [2]. A MetaEdit 2.1 segédprogram az Internet 
Information Server 4 és az IIS 5 metabase szerkesztésére 
egyaránt alkalmas - tehát telepíthető Windows 2000-re és 
Windows NT 4.0-ra egyaránt, a letöltési cím ne zavarjon meg 
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senkit! A MetaEdit a magasabb szintű, ADSI alapú IIS Admin 
Objects és az alacsonyabb szintű, DCOM alapú IIS Base Ad- 
min Objects vegyes használatával oldja meg a rábízott 
feladatokat. Jelenlegi verziójában, amely helyi telepítést 
igényel az IIS-t futtató számítógépre, már letiltották az LM 
és a Schema főcsomópontok törlési lehetőségét. Kifinomult 
exportálási és importálási lehetőségekkel rendelkezik, amely- 
lyel egy vagy több kulcsot lehet szöveges állományba kiírat- 
ni és onnan visszatölteni, valamint teljes IIS web és FTP 
szerverek beállításait tudjuk egy külön opció használatával 
mozgatni több gép között. Ezzel a funkcióval a globális szol- 
gáltatás-beállítások valamint az anonim webfelhasználó ne- 
ve és jelszava kivételével minden paramétert átadhatunk, 
tehát ezt kiegészítő mentésként is alkalmazhatjuk. 
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a MetaEdit 2.1 - az átfogó GUI megoldás 


Szabványos ADSI lekérdezések: Adsvw.exe 

Kihasználva a tényt, hogy a metabase tulajdonságait ADSI 
szabványnak megfelelően szolgáltatja az IIS, egy általános 
ADSI segédprogram is bevethető a lekérdezésekre. Szintén 
grafikus felületű, és letölthető a webről: [3]. Itt a metaba- 
se tulajdonságait az AdsPath szintaxissal érhetjük el. Nagy 
előnye az Adsvw.exe-nek, hogy minden ADSI-nak megfele- 
lő címtárat kiolvashatunk vele, legyen az az Active Directo- 
ry ,csupaszon", vagy az Exchange 2000-rel kiegészítve. 


Parancssoros megoldások 

A jó öreg parancssoros vezérlés itt sem kikerülhető, 
ha a MetaEdit-et nem tudjuk/akarjuk használni. A 
9oSystemRootyoWnetpubAdminScripts könyvtárban talál- 
ható adsutil.vbs egy előre (V8BScriptben) elkészített általá- 
nos IIS felügyeleti eszköz, amellyel közvetlenül a metabase 
kulcsokat és értékeiket változtathatjuk. Futtatásához a 
Windows Scripting Host szolgáltatás CScript értelmezőjét 
kell használnunk, amely nem az alapértelmezett a Windows 
2000 esetében. Amikor elindítjuk az adsutil.vbs-t, a Win- 
dows Scripting Host felajánlja, hogy alapértelmezett 
VBScript futtatóvá tegye a CScript.exe-t. Ha nem szeret- 
nénk elállítani a rendszert az eredeti Wscript értelmezőtől, 
akkor parancssorból a ,Cscript.exe adsutil.vbs PARANCS 
elérési útz [cparaméter2]" szintaxissal használhatjuk. A 
parancsok közül (csak példaként említve) a HELP kilistázza 
az elérhető parancsokat és paramétereiket. Az ENUM segít- 
ségével egy adott kulcs szintjén található értékeket, és a 
kulcs alá bejegyzett további kulcsokat listázhatjuk ki. Az 
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ENUM ALL az összes kulcsot és értéket listázza, tehát itt 
elérési utat nem kell megadni. A GET egy konkrét kulcs és ér- 
tékeinek megjelenítésére szolgál. A SET egy konkrét kulcs ér- 
tékének megváltoztatását teszi lehetővé, ahol is az új értéket 
idézőjelek közt, ,érték" formában kell megadni paraméter- 
ként. A CREATE-tel új kulcsot hozhatunk létre, ahol az eléré- 
si út mögött paraméterként a kulcs típusát kell definiálni. 











5 Adsutil.vbs -— metabase ala parancssor 
Az adsutil.vbs futtatási példái: 


Listázás: Adsutil ENUM /smtpsvc/1l 

Kiíratás: Adsutil GET /smtpsvc/1/gueuedirectory 
Beállítás: Adsutil SET /smtpsvc/1l/gueuedirectory 
4 "arj" 

Létrehozás: Adsutil CREATE W3SVC/1/Root/Myvdir 
8, "IIsWebVirtualpir" 


Egyéni fejlesztések - scriptelés, ASP oldalak 

A korábban említett elérési módok közül az Internet Servi- 
ces Manager HTML verziója használja az alábbi módszert: az 
ASP programozás részeként az IIS Admin Objects elérési 
felületet bármilyen Automation-kompatíbilis script-nyelvvel 
használhatjuk (pl.: VBScript, Jscript) vezérelve. Az URL 
elérésekhez hasonló, az ADSI ADsPath szintaxissal érhetőek 
el az objektumok, pl: IIS://LocalHost/W3SVC/1/Root/path. 
Tehát a hagyományos metabase elérési út immáron kiegé- 
szül egy kezdeti paraméterrel, az IIS-t futtató gép megne- 
vezésével, amely lehetővé teszi a távoli adminisztrációt. A 
teljes fejlesztési dokumentáció elérhető a weben: [4]. 


Gyakorlati tanácsok 

Az Exchange 2000 Server SMTP szolgáltatás könyvtárai 
Komolyan megtervezett kiszolgálók esetében szükséges a 
különböző típusú adatok-folyamatok elválasztása, külön fi- 
zikai lemezre helyezése. (Lásd RAID cikkünket e lapszám- 
ban - a szerk.) Az Exchange teljesítménye nagymértékben 
múlik a merevlemez-alrendszeren, főleg nagy terhelésű ki- 
szolgálók esetében. Mivel az Exchange teljes mértékben az 
IIS SMTP service-re épülve oldja meg a levelek küldését-fo- 
gadását, ezért szükség lehet ezen szolgáltatás könyvtárai- 
nak áthelyezésére. Az Exchange nélküli, csak az IIS SMTP- 
re épülő mailrendszerek is igényelhetik ezt a hangolást. 
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Mivel az Inetpub alapértelmezésben a rendszermeghajtóra 
kerül, az smtp szolgáltatás a Mailroot alkönyvtárban lesz, 
a WWWRoot mellett. Míg a WWWRoot-ot egy mozdulattal 
áthelyezhetjük a Internet Services Manager-ben, a default 
SMTP szerverünk könyvtárait (pl.: 0ueue, Badmail) csak a 
metabase közvetlen szerkesztésével tudjuk átállítani. 
További részletek a 0257835-es azonosítójú KB cikkben 
olvashatók. 


Mentés és visszaállítás 

A metabase teljes mentésére használhatjuk az Internet Servi- 
ces Manager-t, vagy a MetaEdit-et, (mindkettő ugyanazt a 
felületet nyújtja erre a célra). Az Internet Services Manager-ben 
a gép ikonján jobb gombot nyomva érjük el a backup/restore 
modult. Innen két kattintással készíthetünk pillanatfelvételt a 
rendszerünkről, mielőtt komolyabban nekiállnánk a potenciáli- 
san végzetes ,finomhangolásnak". A MetaEdit 2.1 Metabase 
menüjének szintén Backup/Restore parancsával indíthatjuk a 
folyamatokat. Katasztrófa vagy helyrehozhatatlan változtatá- 
sok esetében a visszatöltés is ugyaninnen végezhető el. A le- 
mentett metabase állomány automatikusan a XAwinntY 
system32netsrviMetaBack könyvtárba kerül. Ne feledjük, 
hogy a lementett metabase csak ugyanarra a gépre tölthető 
vissza, és újratelepített rendszer sem jöhet szóba a visszaállí- 
táshoz. Programozott felületek esetében az IIS Admin Objects 
TIisComputer objektum Backup módszerével dolgozhatunk. 


Az IIS metabase replikációja fürtözött rendszerekben 
Az alábbi információk természetesen csak a Windows 2000 
Advanced Server változatra vonatkoznak, mivel a fürtözé- 
si technológiát a Standard változat nem támogatja. A 
fürtcsoport létrehozása után az IIS-t a fürtözött erőforrá- 
sok közé a dokumentáció szerint felvesszük. A rendszer 
feltételezi, hogy a webtartalom a megosztott merevleme- 
zen található, vagy a saját merevlemezeken külön szink- 
ronizálva, azonos elérési útvonalon van. Ezután kell le- 
futtatni manuálisan a forrás (mester) kiszolgálón a 
9oSystemroot vo lsystem3z2Ninetsrv könyvtárban az ifissync.exe 
parancsot, paraméterként a célkiszolgáló(k) nevét megad- 
va. A replikáció nem automatikus, ezért változtatások után 
mindig gondoskodni kell a kézi szinkronizációról. 


Köszönet Soczó Zsoltnak, aki először hívta fel a figyelmemet 
a metabase fontosságára! 


Radvánszki Gábor MCP 
SVED Rt. 


A cikkben található URL-ek: 


[1] IIS Platform SDK Programmers Guide 
http://msdn.microsoft.com/library/psdk/iisref/progZhwl.htm 
[2] MetaEdit 2.1 


http://download.microsoft.com/download/iis40/other/4.0/WIN98/EN-US/MtaEdt21.exe 


[3] Adsvw.exe — az ADSI 2.5 SDK része 


http://www.microsoft.com/ntserver/nts/down! loads/other/ADSI25/default.asp 


[4] IIS 5.0 Documentation 


http://windot i "windows2! r/ii. 
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Bevezető 

A Microsoft Windows 2000 Server operációs rendszer elosz- 
tott biztonsági szolgáltatásai biztosítják a hálózat felhaszná- 
lóinak azonosítását, és az erőforrások elérésének szabályozá- 
sát. Az operációs rendszer biztonsági modellje a megbízható 
tartományvezérlőn történő hitelesítésen, a hitelesítési ada- 
tok szolgáltatások közti átadásán és objektumalapú hozzáfé- 
résszabályozáson alapul. A fő szolgáltatások a következők: 
2 Windows 2000 Active Directory szolgáltatás 

Kerberos version 5 hitelesítési protokoll 

a külső felhasználók hitelesítésére nyílt kulcsú titkosí- 
tás használata 

titkosított fájlrendszer (Encrypting File System - EFS) a 
helyi adatok védelme érdekében 

Internet Protocol security (IPSec) a nyilvános hálóza- 
tokon folytatott biztonságos kommunikáció biztosítására 
Emellett a Windows 2000 biztonsági elemei felhasználhatók 
saját alkalmazásainkban, sőt, a Windows 2000 biztonsági 
rendszere integrálható más, Kerberos hitelesítést használó 
operációs rendszerekkel is. 

Ahogy a fentiekből is látható, a Windows 2000 nemcsak a 
funkciókban gazdag hálózatok kialakítását, hanem azok 
biztonságossá tételét is biztosítja. 

A Windows 2000 biztonsági szolgáltatásait úgy alakították 
ki, hogy megfeleljenek az alábbi követelményeknek: 

0 az összes hálózati erőforrás elérése egyszeri bejelentkezéssel 
erős felhasználóhitelesítés és -azonosítás 

biztonságos kommunikáció a belső és külső erőforrások között 
a szükséges biztonsági házirendek létrehozásának és 
kezelésének képessége 

automatikus biztonsági ellenőrzések 

más operációs rendszerekkel és biztonsági protokollok- 
kal való együttműködés 

"0 bővíthető architektúra 

A Windows 2000 biztonsága egyszerű hitelesítési és azono- 
sítási modellen alapul. A hitelesítés bejelentkezéskor azono- 
sítja a felhasználót, és létrehozza a hálózati szolgáltatások- 
kal a kapcsolatokat. Ha a felhasználó azonosítása megtör- 
tént, jogosultságai alapján fér hozzá a hálózat megadott 
erőforrásaihoz. A jogosultságok kiértékelése a hozzáférés- 
szabályozási listákon (access control list - ACL) alapul, me- 
lyek meghatározzák az objektumokhoz (nyomtatók, fájlok, 
hálózati fájl- és nyomtatómegosztások) való hozzáférés en- 
gedélyezett módjait (például írás engedélyezve, törlés tiltva) . 
Ez a biztonsági modell még a nagykiterjedésű hálózatokban 
sem akadályozza a felhasználók munkavégzését, de jó vé- 
delmet nyújt a támadások ellen. 

A tartományi ügyfél először bejelentkezik a tartományve- 
zérlőre. Azonosítatlan felhasználó soha nem fér hozzá a há- 
lózat erőforrásaihoz (kivéve az anonymous elérésű szolgálta- 
tásokat - a szerk.). A hálózati szolgáltatások létrehozzák az 
ügyfél access token-jét, és a kért műveletek végrehajtása 
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előtt a hitelesítéskor keletkezett bizonyítvánnyal azonosít- 
ják az ügyfelet. A Windows operációs rendszer kernele az 
access token-ben levő biztonsági azonosítókat használja 
annak megállapítására, hogy a felhasználónak az adott ob- 
Cikkünkben a Windows 2000 biztonsági szolgáltatásai közül 
a következőkkel foglalkozunk: Active Directory, hitelesítés 
és azonosítás, Kerberos hitelesítési protokoll, nyílt kulcsú 
infrastruktúra (PKI), bizonyítványok támogatása, titkosí- 
tott fájlrendszer (EFS). Bemutatjuk, mire használhatják az 
alkalmazásfejlesztők a Windows 2000 biztonsági szolgálta- 
tásait, és hogyan működnek ezek együtt más operációs 
rendszerek szolgáltatásaival. 


Az Active Directory szerepe 

Az Active Directory kulcsszerepet játszik a biztonságos hálózat 
megvalósításában. Mind a Windows 2000 Server, mind a Win- 
dows 2000 Professional képes az egyes PC-ken tárolt adatok 
megvédésére, de a teljes körű, házirendalapú, a hálózat erőfor- 
rásainak elérését szabályozó biztonsági rendszer megvalósítá- 
sához együttes használatuk ajánlott, mert így képesek kihasz- 
nálni az Active Directory összes elosztott biztonsági funkcióját. 
Az Active Directory központosítja a felhasználókról, hardver- 
eszközökről, alkalmazásokról és a hálózaton található adatok- 
ról szóló információk tárolását, így a felhasználók könnyen 
megtalálhatják, amit keresnek. Itt tárolódnak a hitelesítési és 
azonosítási információk is, melyek biztosítják, hogy csak a 
feljogosított felhasználók érhessék el a hálózat erőforrásait. 
Emellett az Active Directory szorosan integrálva van a Win- 
dows 2000 biztonsági szolgáltatásaival, például a Kerberos 
hitelesítési protokollal, a PKI-val, az EFS-sel, a Security 
Configuration Manager-rel, és a csoportos házirendekkel. 


Az Active Directory alapjai 

A Windows 2000 biztonsági szolgáltatásainak megértésé- 
hez szükséges az Active Directory architektúrájának alap- 
vető ismerete. Ha a Kedves Olvasó nem ismeri jól az Acti- 
ve Directory-t, hasznára válhat a következő rész, az Acti- 
ve Directory rövid áttekintése. 

A Windows NT Server sík címtárszerkezetével ellentétben az 
Active Directory hierarchiában tárolja az adatokat, mely a 
vállalat felépítését tükrözi. Ez nagyobb elérhető méretet és 
egyszerűbb felügyeletet biztosít. A hierarchia létrehozásá- 
hoz az Active Directory tartományokat, szervezeti egysége- 
ket (organizational unit - OU), és objektumokat használ, 
melyek segítségével a hálózati erőforrások egy PC fájl- és 
mappastruktúrájához hasonlóan szervezhetők. 
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5 Az Active Directory hierarchikus felépítése. 





Egy tartomány különböző objektumok (0U-k, felhasználói fió- 
kok, csoportok, számítógépek) gyűjteménye, melyek egy kö- 
zös, biztonságos címtáradatbázisban helyezkednek el. A tar- 
tományok az Active Directory logikai struktúrájának fő ele- 
mei, így nagy szerepet játszanak a biztonsági rendszerben is. 
Az objektumok tartományokba foglalásával elérhető, hogy a 
hálózat felépítése tükrözze a cég szervezeti felépítését. 

A nagyobb szervezeteknek több tartományuk is lehet, ez 
esetben a tartományok hierarchiáját (tartomány) fának (do- 
main tree) nevezzük. Az első létrehozott tartomány a gyö- 
kértartomány (root domain), mely az alatta létrehozott 
(szép képzavar, feltaláltuk a lefelé növő fát! :) ) utódtarto- 
mányok (child domain) szülőtartománya (parent domain). 
Annak érdekében, hogy nagyon nagy szervezetek is belefér- 
jenek az AD-ba, a fákból erdő (forest) alakítható ki. (Ha 
több tartományvezérlő van egy tartományban, az Active Direc- 
tory megadott időközönként minden tartományvezérlőre repli- 
kálódik, így az adatbázisok mindig szinkronizálva vannak. ) 

A tartomány biztonsági határvonalat képez az egységes 
belső biztonsági házirendek, és a más tartományokkal való 
kapcsolat szempontjából. Az adott tartomány rendszergaz- 
dája csak a saját tartományában állíthat be házirendeket. 
A telephely (site) fogalma az Active Directory-ban levő ki- 
szolgálók egy csoportját jelenti, mely a tartományokkal el- 
lentétben nem logikai struktúra, hanem földrajzi elhelyez- 
kedés szerint van kialakítva. Egy telephelyen belül a számí- 
tógépek általában nagysebességű vonalakon kapcsolódnak 
egymáshoz, de előfordulhat, hogy nincs köztük logikai kap- 
csolat. Például egy vállalat központi épületében más-más 
tevékenységeket végző, egymástól független szervezeti 
egységek AD kiszolgálói egy telephelyen vannak még akkor 
is, ha a a tartományok egymástól teljesen függetlenek. 

A szervezeti egységek (0U) az objektumok tartományon 
belüli logikai egységekbe való szervezését szolgáló táro- 
lók. Egy OU tartalmazhat: felhasználói fiókokat, csopor- 
tokat, számítógépeket, nyomtatókat, alkalmazásokat, 
fájlmegosztásokat és más 0U-kat. 

Az objektumok az egyes dolgok (felhasználók, számítógépek, 
hardvereszközök) jellemző attribútumait tartalmazzák. Például a 
felhasználó-objektum tartalmazhatja a keresztnév attribútumot, 
a nyomtató-objektum a színmélység attribútumot, és mindket- 
tő tartalmazhatja a ,hányadik emeleten van" attribútumot is. 
Az információk tartományokba és 0U-kba rendezésével kö- 
zösen felügyelhetők az objektumcsoportok (például fel- 
használók, számítógépek) biztonsági beállításai. A nagyki- 
terjedésű hálózatok kialakításánál óhatatlanul felmerül a 


tech.net! 


A WINDOWS 2000 BIZTONSÁGA (I. RÉSZ) 
kérdés: Hogyan működnek együtt az Active Directory meg- 
bízotti kapcsolatai (trust relationship) és a Windows 2000 
biztonsági rendszere? Nos, lássuk! 


A tartományok közti megbízotti kapcsolatok 

Hogy a felhasználók egyszeri bejelentkezéssel (single sign- 
on) használhassák a hálózat erőforrásait, a Windows 2000 
támogatja a tartományok közti megbízotti kapcsolatok (trust 
relationship) létrehozását. Ezek tartományok között létreho- 
zott logikai kapcsolatok, melyek segítségével az erdő bár- 
mely tartományában hitelesíthetők a felhasználók és számí- 
tógépek, továbbá ezek biztosítják, hogy egyszeri bejelentke- 
zéssel elérhetők legyenek a hálózat azon erőforrásai, melyek- 
hez megfelelő jogosultságokkal rendelkezünk. Ehhez kapcso- 
lódik a tranzitív megbízotti kapcsolat fogalma, mely azt je- 
lenti, hogy a hitelesítési adatok akár több köztes tartomá- 
nyon áthaladva is elérhetik a megcélzott tartományt. Vagyis 
ha A bízik B-ben, és B bízik C-ben, akkor A bízik C-ben is. 

A Windows NT alapú hálózatokban egyirányú, nem-tranzitív 
megbízotti kapcsolatokat lehetett használni. Ezzel ellentét- 
ben a Windows 2000 hálózatokban a tartományok fastruk- 
túrába vannak rendezve, és implicit módon kialakult meg- 
bízotti kapcsolatok vannak köztük, ami főleg nagyméretű 
vállalatoknál egyszerűsíti le a tartományok közti megbízá- 
sok létrehozását (mert nem is kell létrehozni, hanem az AD 
megfelelő telepítésekor magától létrejönnek). Azok a tarto- 
mányok, melyek egy fa tagjai, kétirányú megbízotti kapcso- 
latokat hoznak létre a szülőtartományukkal, ezért az összes 
fában levő tartomány megbízik egymásban. (Ha szükség 
lenne egyirányú, explicit módon megadott megbízásokra, ter- 
mészetesen ilyenek is beállíthatók.) A Windows 2000-re va- 
ló áttéréssel különösen a sok tartományból álló vállalati há- 
lózatokban csökken le jelentősen a megbízotti kapcsolatok 
száma, és ez a tartományok felügyeletét is leegyszerűsíti. A 
tranzitív megbízások automatikusan létrejönnek egy fán 
belül, hiszen általában ekkora egy rendszergazda ,birodal- 
ma", éppen ezért kell külön létrehozni az erdő fái közti 
tranzitív megbízotti kapcsolatokat. 

A megbízotti kapcsolatok szemléltetésére ismét előző ábrán- 
kat hívjuk segítségül. A Windows 2000 automatikusan létre- 
hozza a gyökér- (Microsoft.com), és utódtartományok 
(FarEast.Microsoft.com és Europe.Microsoft.com) között a 
kétirányú megbízásokat. Mivel a Microsoft.com bízik mind- 
két utódtartományában, ezzel létrejön az utódtartományok 
közti tranzitív megbízotti kapcsolat is. Ezek a megbízások a 
Windows 2000 tartományok között automatikusan jönnek 
létre. A vegyes (NT és 2000) hálózatok tartományai között 
a rendszergazdáknak kell explicit módon megadni az egyirá- 
nyú megbízásokat, ugyanúgy, mint az NT-s hálózatokban. 
A tartományok közti hitelesítést a Windows 2000 a Kerbe- 
ros V5 protokoll, és a régi rendszerekkel való együttműkö- 
dés érdekében az NTLM használatával biztosítja. Mivel a 
Windows 2000 tartományfája tranzitív megbízások rend- 
szerét támogatja, nagyvállalatoknál leegyszerűsödhet a 
tartományok összekapcsolása és felügyelete. Fontos, hogy 
a tranzitív megbízások nem biztosítanak automatikusan 
olyan jogosultságokat, melyek az ACL-ekben nem szerepel- 
nek, ,csak" egyszerűbbé teszik azok beállítását. 
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A biztonság felügyelete csoportos házirendekkel 

A csoportos házirendek (Group Policy) beállításaival az Active 
Directory objektumainak viselkedése szabályozható. A csoportos 
házirendek kezelése az Active Directory igen fontos funkciója, 
mert segítségével egyidejűleg sok számítógépen egységesen ér- 
vényesíthetők különféle beállítások. Például segítségükkel elvé- 
gezhetők biztonsági módosítások, és felügyelhetők az alkalma- 
zások. A számítógépek csoportos házirendjei rendszerbetöltés- 
kor, a felhasználóké pedig bejelentkezéskor érvényesülnek, és — 
ellentétben az NTA házirendjeivel - időről időre frissülnek még 
akkor is, ha a felhasználó nem jelentkezik ki-be. 

Az Active Directory háromféle tárolótípusára adhatók meg cso- 
portos házirendek: 0U-kra, tartományokra és telephelyekre. Az 
adott tárolóra érvényes csoportos házirend érvényesülhet az 
összes objektumon, vagy azok meghatározott csoportján. 

A csoportos házirendek alkalmazhatók széles körben érvényes 
biztonsági házirendek megadására. A tartományszintű házi- 
rendek érvényesek a tartomány összes felhasználójára, és tar- 
talmazhatják például a minimális jelszóhosszt és jelszóváltoz- 
tatás gyakoriságát megadó házirendeket. Beállítható az is, 
hogy alacsonyabb szinten felülbírálhatók-e ezek a beállítások. 
A széleskörű biztonsági házirendek érvényesítése mellett 
lehetőség van az egyes PC-k biztonsági beállításainak fi- 
nomhangolására is. A számítógépek helyi biztonsági beállí- 
tásainál megadhatók a felhasználók és más számítógépek 
jogosultságai. Ezekkel határozható meg például, hogy ki 
végezheti el a kiszolgáló biztonsági mentését, vagy ki au- 
ditálhatja az asztali gépeken levő adatok elérését. 

Az adott számítógép beállításai végül a házirendekben 
megadott szabályok összessége lesz. 


Hitelesítés és hozzáférésszabályozás 

A hitelesítés fontos része a rendszer biztonságának. Arra 
szolgál, hogy a tartományba bejelentkező, vagy hálózati 
erőforrást használni akaró felhasználó személyazonosságát 
megállapítsuk. A Windows 2000 hitelesítése része annak a 
folyamatnak, mely biztosítja, hogy a felhasználó egyszeri 
bejelentkezéssel elérje a hálózat erőforrásait, és hitelesítse 
magát a hálózat bármely számítógépén. 

A sikeres felhasználóhitelesítés két részből áll. Az elsőnél, az in- 
teraktív bejelentkezésnél a felhasználó által megadott azonosí- 
tók összevetésre kerülnek a tartományi-, vagy helyi fiók azono- 
sítóival. A második, a hálózati hitelesítés a felhasználói azonosí- 
tók alapján jóváhagyhatja bármely hálózati szolgáltatás elérését. 
Ha a felhasználó hitelesítve van, és elérhet egy objektumot, 
akkor a neki kiosztott, vagy az objektumra érvényes jogo- 
sultságok alapján kerül meghatározásra az engedélyezett 
elérés típusa. A tartományi objektumokon az objektumtípus 
objektum-kezelője kikényszeríti a hozzáférési szabályok ér- 
vényesítését (például a rendszerleíró adatbázist csak a kul- 
csaira érvényes jogosultságok erejéig bántalmazhatjuk) . 


Hitelesítés 

A felhasználónak rendelkeznie kell egy Active Directory-ban 
tárolt felhasználói fiókkal, hogy bejelentkezhessen egy szá- 
mítógépre, vagy egy tartományba. Az operációs rendszer 
ezt használja a felhasználó hitelesítésére és a tartomány- 
ban levő erőforrások elérésének engedélyezésére. 

A felhasználói fiókok használhatók szolgáltatás-fiókként, 
vagyis akár egy szolgáltatás is bejelentkezhet felhasználó- 
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ként (hitelesíti magát) , és így a felhasználói fiók jogosult- 
ságainak megfelelő műveleteket hajthat végre. 
A felhasználói fiókokhoz hasonlóan, a Windows 2000 szá- 
mítógép-fiókok is egyfajta hitelesítést biztosítanak a szá- 
mítógép hálózat- és erőforrás-elérésekor. Minden Windows 
2000-es számítógépnek, amelynek erőforrás-elérést akarunk 
engedélyezni, rendelkeznie kell egyedi számítógép-fiókkal. 
Mivel a Windows 98 és 95 nem rendelkezik a Windows NT 
és 2000 fejlett biztonsági funkcióival, nem osztható ki ne- 
kik számítógépfiók, de be lehet jelentkezni róluk a tarto- 
mányba, és használni lehet annak erőforrásait. (Ha bizton- 
ságos tartományt akarunk kialakítani, ne használjunk ben- 
ne Windows 9x-et futtató számítógépeket!!! Ezek ugyanis 
nem biztonságos hitelesítést használnak. Korábbi lapszá- 
munkban olvasható ugyan megoldás arra, hogy ezeken az 
operációs rendszereken NTLMv2 hitelesítést alkalmazzunk, 
de ne feledjük, hogy magát a számítógépet és az azon levő 
adatokat ekkor sem védi semmilyen biztonsági rendszer.) 
A Windows 2000 többféle hitelesítési eljárást biztosít a hálózat- 
ra belépő felhasználók személyazonosságának minden kétséget 
kizáró megállapítására. Amikor a felhasználó belép a hálózatra, 
hitelesítési információkat kell szolgáltatnia a biztonsági rend- 
szernek, amely így ellenőrizheti személyazonosságát, és eldönt- 
heti, hogy milyen hozzáférést engedélyez a felhasználónak. 
Az összes igény kielégítése érdekében a Windows 2000 támo- 
gatja a legtöbb szabványos hitelesítési eljárást (például X.509 
bizonyítványok, intelligens kártyák, Kerberos protokoll) . Emel- 
lett a Windows 2000 támogatja az évek óta használt NTLM pro- 
tokollt, és csatolófelületet biztosít a biometrikus (ujjlenyo- 
mat, retina) hitelesítési eljárások alkalmazásához. 
A csoportos házirendekben a felhasználóknak és csoportok- 
nak szerepkörük, és persze igényeink szerint megadhatók az 
alkalmazott hitelesítési eljárások. Például érzékeny adato- 
kat használó vezetőinket intelligens kártyák, Internetes vá- 
sárlóinkat X.509 bizonyítványok használatára kötelezhet- 
jük, a ,mezei" felhasználóknál pedig továbbra is nyugodtan 
alkalmazhatjuk az NTLM hitelesítést. A hitelesítési eljárás- 
tól függetlenül a Windows 2000 mindig az Active Directo- 
ry-t használja az eljárás során kapott adatok ellenőrzésére. 
Ha a hitelesítés sikeres, és a hitelesítési eljárás során szolgál- 
tatott adatokhoz felhasználói fiók rendelhető hozzá, a Win- 
dows 2000 ellátja a felhasználót meghatalmazásokkal, melyek 
a hálózat erőforrásaihoz való hozzáférésre használhatók. 


Hozzáférésszabályozás 

A Windows 2000 a hozzáférésszabályozást az objektumokhoz 
(fájlok, nyomtatók, szolgáltatások) rendelt biztonsági leírók- 
kal valósítja meg. Egy objektum biztonsági leírója egy ACL-t 
tartalmaz, ami meghatározza, hogy mely felhasználónak mi- 
lyen jogosultsága van. Ez adja meg azt is, hogy mely objek- 
tumelérési eseményeket (például a fájl írása) kell naplózni. 
Az objektum tulajdonságainál beállíthatók a jogosultságok, 
és naplózhatók a felhasználók objektum-elérései. 

A Windows 2000 megújított biztonsági rendszerében az ob- 
jektumok egyes attribútumaihoz való hozzáférést is szabá- 
lyozhatjuk. Például az objektum biztonsági leíróinak megfe- 
lelő beállításával a felhasználók számára látható lehet egy 
alkalmazott neve és telefonszáma, de az otthoni címe nem. 
Az objektum ACL-jét használva a Windows 2000 összeha- 
sonlítja az ügyféltől származó információt (személyazonos- 
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ság, csoporttagság) az objektumról szóló információkkal 
(ACL), és eldönti, hogy a felhasználónak megvannak-e a 
jogosultságai az objektumon (például egy fájlon) a kért 
művelet végrehajtásához (például írás/olvasás) . A hozzáfé- 
rés ellenőrzése a Windows 2000 biztonsági alrendszerén 
belül, kernel módban történik. Az összehasonlítás eredmé- 
nyétől függően az ügyfél értesítést kap a szolgáltatás meg- 
kezdéséről, vagy annak megtagadásáról. 


A hozzáférésszabályozás finomhangolása 

A biztonsági beállítások nagyobb rugalmassága érdekében 
az Active Directory lehetővé teszi a címtárobjektumok hoz- 
záférésszabályozásának finomhangolását. A címtárobjektu- 
mok gazdagon felcicomázhatók jellemzőkkel, s ezeket akár 
egyesével is védhetjük. Egy felhasználónak vagy csoportnak 
akár több száz attribútuma is lehet (például telefonszámok, 
főnök, csoporttagság) . A felhasználói fiók kiválasztott tulaj- 
donságaira, vagy attribútumaira más-más jogosultságok ál- 
líthatók be. A naplózás is tulajdonságszinten állítható be. 


A rendszerfelügyelet átadása 

Mivel a vállalatok több alkalmazott között oszthatják el a tar- 
tományfelügyeleti teendőket, az Active Directory biztosítja 
az erdőn, vagy tartományon belül a felügyeleti feladatrészek 
átadását. A szervezeti egységek létrehozásával a tartomány- 
fa bármely szintjére leoszthatók a felügyeleti teendők, úgy, 
hogy egy szervezeti egységbe helyezzük azokat az objektu- 
mokat, melyek felügyeletét másra akarjuk bízni, majd az 0U 
felügyeletét a kívánt személyre vagy csoportra bízzuk. 

OU szinten a rendszergazdák jogot adhatnak például csopor- 
tok létrehozására, a csoportok taglistáinak szerkesztésére, 
vagy számítógépfiókok tartományhoz való hozzáadására. A 
csoportos házirendek beállításai és a felhasználói csoportok 
használata lehetővé teszik a rendszergazdáknak a kiosztott 
felügyeleti terület pontos meghatározását. Például a fel- 
használó-rekordok módosításának területe kiosztható egy 
felhasználói csoportnak, de a csoport fennhatósága egy ki- 
választott felhasználókból álló részhalmazra korlátozható. 
Emellett, a hozzáférés-szabályozás finomhangolásával le- 
szűkíthető a kiosztott felügyeleti feladatok köre. Például a 
kiválasztott csoportnak nem kell a felhasználói fiókok re- 
kordjaihoz mindenre kiterjedő jogokat adni, amikor elég a 
jelszavak törlését engedélyezni. 


A Kerberos hitelesítési protokoll 

A Windows 2000 elsődleges felhasználóhitelesítési módszer- 
ként az Internet szabványnak megfelelő Kerberos V5 proto- 
kollt (RFC 1510) használja. A Kerberos protokoll kölcsönös hi- 
telesítési eljárás, mely a kiszolgáló és az ügyfél között, a köz- 
tük megnyíló hálózati kapcsolat létrehozása előtt zajlik le. 

A Kerberos hitelesítés jegyeken (ticket) alapul. Amikor az 
ügyfél bejelentkezik a Windows 2000 tartományba, kap 
egy jegyet, mely arra szolgál, hogy azonosítsa a hálózati 
erőforrás számára az ügyfelet, és az ügyfél számára a há- 
lózati erőforrást. Ennek megvalósításához a Kerberos sha- 
red secreten (jelszavakon) alapuló hitelesítést használ. A 
módszer alapját képező elgondolás igen egyszerű: ha csak 
a két fél tudja a titkot, bármelyik megbizonyosodhat a má- 
sik személyazonosságáról azzal, ha meggyőződik róla, 
hogy a másik tudja a titkot. 
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A Kerberos protokoll esetén az ügyfél és a kiszolgáló is 
nyilvántartásba kerül a Kerberos hitelesítő-kiszolgálón. A 
Kerberos hitelesítést használó ügyfelek a felhasználó jel- 
szaván alapuló, titkosított információt küldenek a Kerbe- 
ros kiszolgálónak, amely így megbizonyosodhat a felhasz- 
náló személyazonosságáról. A kiszolgáló ugyanígy küld in- 
formációt az ügyfél Kerberos szoftverének, amely így meg- 
bizonyosodhat arról, hogy a kiszolgáló tényleg az-e, aki- 
nek mondja magát. Ez a kölcsönös hitelesítési folyamat 
mind az ügyfelet, mind a kiszolgálót megvédi a másik fe- 
let megszemélyesítő rosszindulatú ,kalózoktól". 

A Kerberos fejlődést jelent a Windows NT 4.0 hitelesítési folya- 
matához (NTLM) képest, ahol az ügyfélnek minden egyes erő- 
forrás elérésekor külön hitelesíteni kellett magát. A Kerberos le- 
váltja az NTLM protokollt, de a régi rendszerekkel való együtt- 
működés érdekében a Windows 2000 támogatja az NTLM-t is. A 
teljes körű Kerberos protokoll-támogatás nemcsak a Windows 
2000 rendszerek esetén biztosít gyors, egyszeri bejelentkezést, 
hanem minden olyan rendszernél, amely támogatja ezt. 


A Kerberos hitelesítési folyamat 

A Kerberos hitelesítési protokoll az ügyfelek és a kiszolgálók 
azonosítóinak ellenőrzését, és megfelelő helyre való eljutta- 
tását végzi. Amikor a felhasználó bejelentkezik a Windows 
2000 tartományba, a Windows 2000 keres (DNS, oh DNS, 
légy jó mindhalálig!) egy Active Directory kiszolgálót, és egy 
Kerberos hitelesítési szolgáltatást, és az ügyfél azonosítóját 
eljuttatja a Kerberos szolgáltatáshoz. Az ügyfél a jelszóból 
származó, kiszolgáló által ellenőrizhető kulccsal, vagy (in- 
telligens kártya használata esetén) a titkos kulccsal (melynek 
nyilvános fele az Active Directory-ban megtalálható) titkosí- 
tott információval hitelesíthető. Az ügyfél hitelesítési infor- 
mációinak ellenőrzése után a kulcselosztó központnak (Key 
Distribution Center - KDC) nevezett Kerberos szolgáltatás ad 
a felhasználónak egy további jegyek kérésére alkalmas je- 
gyet (ticket-granting ticket - TGT), amely ezután az ügyfél 
azonosítására szolgál, amikor a hálózati erőforrások elérésé- 
hez további jegyeket igényel. (A TGT használatával a KDC- 
nek kevesebbszer kell az ügyfélről szóló információkat kérnie. ) 
Bár a fent leírt folyamat nagyon bonyolultnak tűnik (és az 
is), a felhasználónak csak a jelszavát kell beírnia. 

Az alábbi ábrán látható az ügyfél, a KDC és a kiszolgáló 
Kerberos protokoll használata közbeni kapcsolata. 





AZ) 4. Verifies 
Session ticket 
issued by KDC 


j 3. Presents 
session ticket at 
Il conn 





1. client logs on and 
receives ticket 
granting ticket (TGT) 
from KDC. 


Directory Server 


Key Distribution 
Center (KDC) 


Mesés 


Windows Domain Controller 


4-b] 


2. Client presents TGT 
to KDC in exchange 
for session tickets for 
each recource to be 
accessed 





5 A Kerberos hitelesítés folyamata. 
(Folytatjuk...) 
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Bevezetés 

Még be sem fejeződött az SOL Server 7 fejlesztése, és máris 
több oldalas volt az SOL Server fejlesztő csapat , kívánságlis- 
tája", azaz, hogy a megoldásszállító fejlesztők milyen funk- 
ciókat szeretnének látni a következő SOL Server verzióban. 
Ennek eredményeként született - az XML támogatás mellett 
- az SOL 2000 legnagyobb újítása a felhasználói függvények 
formájában. A cikkben nagyon tömören megnézzük a téma 
elméleti hátterét, hogy azután megírjunk néhány függvényt, 
amelyek segítségével szövegeket manipulálunk, megírjuk a 
Basic Split függvény SOL párját, megtanulunk körlevelet kül- 
deni felhasználói függvényekkel, és kifejlesztünk egy beha- 
tolásjelző programot. Hosszú, de nagyon izgalmas rész lesz 
ez cikksorozatunkban, érdemes végigolvasni! 


Minden, amit tudni akartál a felhasználói függvények- 
ről, de nem merted megkérdezni 

Ez a rész a felhasználói függvények lelkivilágával, formai és mű- 
ködésbeli tulajdonságaival foglalkozik. Aki tudja, miért fontos 
a determinizmus kérdése a függvényeknél, az nyugodtan ugor- 
jon az utolsó fejezetre, ahol fokozatosan bonyolódó példákat 
találhat. Aki nem, az tartson velem a következő részekben is. 

Az SOL Serverben nagyon sok beépített függvény található 
(lásd cikksorozatunk előző része), azonban ezek nyilvánva- 
lóan nagyon általános függvények, mint például a (ruha- 
iparból ismert) LEN függvény, ami egy szöveg hosszát adja 
vissza. Nagyon jók ezek a beépített függvények, köszönjük 
őket, de a gyakorlati problémák megoldásához - pont az ál- 
talános voltuk miatt - nem elegek. Mint építőkockák kitű- 
nőek, de hogyan építünk belőlük várat? Nos, hosszú vára- 
kozás után a Microsoft elékészítette a habarcsot, megalkot- 
ta a felhasználói függvényeket, így most már semmi akadá- 
lya, hogy megalkossuk a saját PAMUT vagy a GYAPJU nevű 
függvényeinket, amelyek belső működését mi írhatjuk elő. 
Egyszerűen megfogalmazva a felhasználói függvény olyan 
Transact SOL utasítások sorozata, amelyeket azért csoma- 
golunk egybe, hogy több helyen is felhasználhassuk. Na- 
gyon jól kiegészítik a tárolt eljárásokat, mert minden olyan 
helyen felhasználhatjuk őket, ahol a beépített függvénye- 
ket is, azaz ahol a tárolt eljárásokat legtöbbször nem. A 
legegyszerűbb példa erre a SELECT-ben való felhasználás. 
Például, ha van egy osszeadas nevű függvényünk, akkor azt 
felhasználhatjuk két oszlopban található számok összeadá- 
sára, a SELECT utasítás részeként: 


SELECT osszeadas(Ár, ÁFA), Termék FROM ... 


Ennél kevésbé kézenfekvő helyeken is használhatjuk a függ- 
vényeinket: WHERE feltételben, HAVING-ben, CHECK CONST- 
RAINT-ekben, DEFAULT CONSTRAINT-ekben, számított osz- 
lopok képzésében. Mindenhol működnek, ahol a szerver va- 
lamilyen kifejezést vár (mint azb, c-4 vagy 2x2-5). 
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(IV. rész) 


Azok kedvéért, akik nem szeretnek tömény oldalakat kódok nél- 
kül látni, megmutatom az előbbi függvény deklarációját. Rész- 
letes magyarázatot a cikk második felében talál a lelkes Olvasó. 


CREATE FUNCTION osszeadas 
( 

Ca INT, 

éb INT 


RETURNS INT 
BEGIN 

RETURN €a t Eb 
END 


Az SOL Server a függvényeket sokszor tranzakciók, illetve 
SELECT, UPDATE, satöbbi utasítások kellős közepén hívja 
meg. Emiatt rendetlen az a függvény, ami menet közben 
módosítja egy tábla tartalmát, miközben egy SELECT (ami őt 
hívta meg) éppen dolgozik rajta - nos ilyen esetben nagy 
lárma és kalamajka támadhatna. Az SOL Server azonban nem 
keresi a bajt, ezért megpróbálja megkötni a kezüket, hogy 
ne csináljunk felfordulást. Azaz a felhasználói függvények- 
ben nem tehetünk meg akármit, csak a következőket: 

"2 Definiálhatunk saját változókat és kurzorokat a DECLA- 
RE utasítással. Csak lokális kurzorokat készíthetünk így, 
globálisakat, azaz amelyek a függvény lefutása után is 
léteznének nem. 

"0 A függvényben deklarált lokális változóknak értéket ad- 

hatunk (naná, e nélkül akár ki is dobhatnák a függvé- 

nyeinket) . 

Használhatunk kurzorműveleteket, de csak úgy, hogy a 

FETCH utasítás eredményeit lokális változókba rakjuk el 

(a kurzorokkal egy teljes cikk fog foglalkozni a következő 

hónapban). 

Bevethetjük a programfolyam-vezérlő utasításokat: if, 

then, for, while, goto, satöbbi. Ezek nélkül nem is le- 

hetne egy komolyabb függvényt megírni. 

- Alkalmazhatjuk az összes adatmódosító utasítást (IN- 
SERT, UPDATE, DELETE), ha azok csak lokális táblákon 
végeznek műveleteket. Ebből következően nem lehet 
módosítani külső táblákat. Természetesen lekérdezések- 
ben szerepelhetnek. 

"8 Meghívhatunk külső tárolt eljárásokat (Extended Stored 
Procedure) az EXECUTE utasítással. , Hagyományos" tá- 
rolt eljárásokat nem lehet meghívni belőlük, hisz azok- 
ból már könnyedén beavatkozhatnánk a ,külvilágba". 

Látható, hogy minden pontban arról van szó, hogy megte- 

hetünk szinte bármit, amit csak akarunk, de csak lokálisan, 

azaz a függvény nem avatkozhat be a külvilágba. Van egy 
kis szemétdombunk, ott kapirgáljunk. Bár az utolsó pont, 
azaz, hogy külső tárolt eljárásokat is meghívhatunk, azért 
egy nagyon tág fogalom. Mert mit csinálhat egy külső tá- 
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rolt eljárás? Bármit! Amit akar. Azaz például megteheti azt, 
hogy visszafelé nyit egy kapcsolatot a kiszolgálóra, és azon ke- 
resztül megváltoztatja azt a táblát, amiben éppen dolgozik a 
kódunk a függvény hívása során. De ez általában már túlmutat 
a normális használaton. Megtehették volna a fejlesztők, hogy 
teljesen letiltják a külső eljáráshívásokat, de akkor meg eles- 
tünk volna olyan nagyszerű lehetőségektől, mint külső paran- 
csok meghívása (xp. cmdshell), levélküldés (xp. sendmail) vagy 
event log írás (xp. logevent) (és még sok egyéb hasznos funkció). 
Az imént felsorolt három külső tárolt eljárás azonban pont 
olyan, aminek nem szabadna lefutni egy függvényben. 
Miért? Azért mert egy függvény nem változtathatja meg glo- 
bálisan a rendszer állapotát. A rendszeren nem csak az SOL 
Server belső lelkivilágát értjük, hanem az egész világot. Így 
például az xp cmdshell segítségével akár le is formázhatjuk 
kollégánk merevlemezét. Fogadjunk, hogy megváltozik a 
kolléga (lelki)állapota. :) Azaz ezeket a külső tárolt eljárá- 
sokat nem szabadna meghívni egy felhasználói függvényből, 
amire nyomatékosan fel is hívja a figyelmet a dokumentáció 
(Books Online). Azonban, a fordító egy szót sem szól, ha 
olyan függvényt írunk, amiben felhasználjuk a veszélyes tá- 
rolt eljárások valamelyikét! Ezt még ki fogjuk használni a 
cikk végén található programokban. Pont olyan ez, mint a C 
programozás: ha meggondoltan csináljuk, miénk a világ. Ha 
nem, akkor csak General Protection Fault-okat generálunk. 


A nemdeterminisztikus jövő 

Vannak még más problémás elemek is, amelyeket bizonyos 

esetekben szintén nem szabad használni függvényekben. 

Ezek a nemdeterminisztikus függvények. Mik is ezek? Ők a 

függvények azon fajtái, amelyeknek a működése vagy az ál- 

tala visszaadott érték időben vagy a szerver állapotától füg- 
gően nem megjósolható módon változik. Azaz ugyanazokkal 

a paraméterekkel meghívva egyszer a-t mond, másszor b-t. 

A legegyszerűbb példa erre a GetDate() beépített függvény, 

ami a pillanatnyi időt adja vissza (a GetTime szerencsésebb 

név lett volna) . Ez minden egyes meghívás pillanatában más 

értéket ad vissza, legalábbis addig, amíg jár a gépünkben a 

kvarckristály. A fordítóprogram nem engedi meg, hogy ilyen 

nemdeterminisztikus beépített függvényeket helyezzük el a 

saját függvényeinkben. Például a következő függvény törzs- 

re: RETURN RAND(10) a fordító az ,Invalid use of "rand" wi- 
thin a function." hibaüzenettel válaszol. 

Miért ilyen problémás pont a determinizmus kérdése az SOL 

Serverben? Azért, mert vannak benne olyan új szolgáltatá- 

sok, amelyek nem tudnának helyesen működni a , bizonyta- 

lan" nemdeterminisztikus függvényekkel. Két helyen nem 
lehet felhasználni a nemdeterminisztikus függvényeket: 

"8 Indexelt számított oszlopokon, azaz, ha olyan oszlop 
ra szeretnénk indexet készíteni, amelynek érékei egy 
másik (egy vagy több) oszlopból származnak, és a szá- 
mított érték valamilyen nemdeterminisztikus függvé- 
nyen alapul. 

"0 Olyan nézetekben, ahol a nézetre clustered indexet 
szeretnénk használni. 

A két megszorítás alapján már eléggé érthető, hogy miért kell 

foglalkozni a determinizmus kérdésével. Mindkét esetben in- 

dexet építünk táblában található adatokra. Próbált már vala- 
ki megülni egy vásári bikát? Nem egyszerű. Hasonló módon az 

SOL Server sem tud indextáblát építeni olyan adatokra, ame- 
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lyek minden pillanatban változnak. A clustered index az ada- 
tok fizikai sorrendjét határozza meg. Ezen a héten így legyek 
sorban az adatok, a következő héten meg másképp, csak 
azért, mert meggondolta magát a transzformáló függvény? Na 


nem, ez nonszensz lenne. Ezért nem is tehetünk ilyet. 


Ragaszkodás a barátokhoz 

Egyetlen apró fogalom maradt már csak hátra, hogy tény- 
legesen megírhassuk első függvényünket. Ez a séma-kötés 
fogalma. A felhasználói függvények igen erősen kötődnek 
azokhoz a táblákhoz, és egyéb objektumokhoz, amelyekre 
hivatkoznak. Ha azok módosulnak anélkül, hogy erről a 
függvény tudna, akkor a kapcsolatuk vége barátságtalan 
lesz, és a függvény nem fog jól működni. Azért, hogy a jó 
viszonyban ne következhessen be szakadás, a függvény 
létrehozásakor (CREATE FUNCTION) megadhatjuk, hogy a 
függvény legyen hozzákötve az általa használt objektu- 
mokhoz. Ezt az SOL Server megjegyzi, és nem engedi mó- 
dosítani vagy törölni az ily módon leláncolt objektumokat. 
A kötés jelzését a RETURNS és a függvény törzsét kezdő 
BEGIN közé kell írni: 


RETURNS ... 
WITH SCHEMABINDING 
BEGIN 


Függvénytípusok 

Háromféle felhasználói függvénytípust hozhatunk létre az 

SOL 2000-ben: 

0 Skaláris függvények, melyeknek visszatérési értéke 

skaláris, azaz egy érték (scalar functions) 

Egy utasításból álló, tábla visszatérési értékű függvé- 

nyek (inline table valued functions) 

) Több utasításból álló, tábla visszatérési értékű függvé- 
nyek (multi statement table valued functions) 

Az utóbbi két fajta nagyon hasonlít egymásra, mint ez a 

részletes tárgyalásból hamarosan kiderül. 


Skaláris függvények 

A skaláris függvények nagyon egyszerűek: kapnak néhány 
paramétert, azokon végeznek valamilyen művelet, majd az 
eredményt egy skaláris értékként visszaadják. Azaz visszaad- 
nak egy számot, egy szöveget, egy dátumot satöbbi. Legin- 
kább a procedurális nyelvek függvényeihez hasonlítanak. 
Rutinos tárolt eljárás programozók! A felhasználói függvé- 
nyeknek nincsenek kimeneti paramétereik! Azaz nem lehet 
valamelyik paramétert megjelölni, hogy az visszafelé fog 
majd valamilyen információt szolgáltatni a hívónak. Ezt a le- 
hetőséget azért kellett bevezetni a tárolt eljárásoknál, mert 
azok csak egy egész számot tudnak visszaadni visszatérési 
értékként, így nem tudtunk volna például egy dátumot 
visszaadni a hívónak. Erre szolgáltak a kimeneti paraméterek. 
Hogy teljesen érthető legyen, álljon itt egy tárolt eljárás, 
amelynek a harmadik paramétere kimeneti paraméter: 
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CREATE PROCEDURE osszead 

ta INT, 

éb INT, 

éc INT OUTPUT 
AS 
SET éG - Pa 4 éb 
--Eddig a tárolt eljárás deklarációja. 
--Látható, hogy egy tárolt eljárásban nem 
--kötelező a visszatérési értéket megadni 
--Azaz lehetne egy záró RETURN ..., de 
--nem szükséges, mert most nem használjuk 


--fel a visszatérési értéket. 


DECLARE Éosszeg INT 


--hívjuk meg 


EXECUTE osszead 1,4, Gosszeg OUTPUT 
SELECT Gosszeg 
5  --Működik! 


Nos, kimeneti paraméter nincs a felhasználói függvények- 
ben. Viszont segítségükkel sokkal egyszerűbben meg lehet 
fogalmazni az előbbi problémát: 


CREATE FUNCTION osszeadas( 
Ca INT, 
Eb INT) 
RETURNS INT 
BEGIN 
RETURN 8a 4 éb 
END 


SELECT dbo.osszeadas(1,4) 


Azért ez sokkal természetesebb, mint a tárolt eljárásos vál- 
tozat. De azért szedjük csak szét ízekre a függvény deklará- 
ciót! A CREATE FUNCTION jelzi, hogy ez egy felhasználói 
függvény lesz. Ezután jön a függvény neve. Általában a 
függvényeknek vannak paramétereik, ezeket zárójelben so0- 
roljuk fel a függvény neve után. A 2 nem opcionális, nem 
esztétikai okokból raktam bele, vagy azért, mert ettől olyan 
tudományos lesz, hanem azért, mert Transact SOL-ben min- 
den változót kötelező 2-al kezdeni. A paraméter neve után 
meg kell adni az ő típusát. Itt majdnem az összes, a kiszol- 
gáló által támogatott adattípust fel lehet használni, egy- 
két elvarázsolt image, text vagy cursor típust kivéve. A RE- 
TURNS után kell definiálni a visszatérési érték adattípusát. 
A kötöttségek ugyanazok, mint a paramétereknél, azaz csak 
normális" változókat használhatunk. A függvény törzsét, 
ahol az általunk megálmodott funkcionalitást írjuk le, a BE- 
GIN és END kulcsszavak közé kell elhelyezni. Ennyi. 
Mondja azt valaki, hogy bonyolultak a felhasználói függvé- 
nyek! Ha a fenti mintapélda kéznél van, minden problémát 
csuklóból megoldunk. Persze enyhe túlzással, és ha egy ki- 
meneti érték elég a feladat leírásához. :) 

Még egy fontos tudnivaló. A skaláris visszatérési értékű függ- 
vényekre minimum 2 tagú névvel kell hivatkozni. Azaz legalább 
a függvény tulajdonosát meg kell adnunk ahhoz, hogy az SOL 
Server felismerje a függvényünket. Ennek megfelelően, a: 
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SELECT osszeadas(1,4) 
hibát fog jelezni. Helyesen: 


SELECT dbo.osszeadas(1,4) vagy 
SELECT Northwind.dbo.osszeadas(1,4) 


De mi van, ha több értéket kell visszaadnunk? Mi van, ha 
ráadásul azt sem tudjuk, hogy igazából hány kimeneti érté- 
künk lesz, mert azt a tábláinkban található információk pilla- 
natnyi állapota szabja meg? Ebben az esetben kapaszkodunk 
a tábla kimenetű felhasználói függvényekbe. (A továbbiakban 
nem írom ki mindenhol a felhasználói jelzőt, de ott van.) 

Ezt értsük úgy, hogy, ha a skaláris függvények egy skaláris 
mennyiséget adnak vissza, akkor a tábla kimenetűek meg 
egy táblát? Igen. De, hát nincs is ilyen adattípus az SOL 
Server 7-ben! Abban tényleg nincs, de az SOL 2000-ben 
van. És nagyon szeretjük is őket. Képzeljük el: van egy 
olyan változótípusunk, ami akár egy tízmillió sorból és hu- 
szonhat oszlopból álló teljes táblát el tud tárolni. Csoda, 
hogy szeretjük? Ez a tábla (table) adattípus. 

Miért olyan szenzációs ez? Eddig is létre lehetett hozni át- 
meneti táblákat, és azokba is lehetett ideiglenes eredmé- 
nyeket beleírni. Persze, de a tábla adattípus felhasználásá- 
val egyrészt átláthatóbban, a természetes gondolkodáshoz 
közelebb álló kódot hozhatunk létre, másrészt olyan dolgo- 
kat is megvalósíthatunk, amelyeket korábban csak nagyon 
trükkösen vagy sehogyan sem tudtunk megtenni. 

Hol használhatjuk fel a tábla kimenetű függvényeket? Min- 
den olyan helyen, ahol eddig egy táblát adhattunk meg. 
Azaz leginkább a FROM záradék után. 


SELECT cica, egér 
FROM AzElsoTablaFuggvenyem( "sajt" ) 


Paraméterezett nézetek felhasználói függvényekkel, 
avagy az egy utasításból álló, tábla visszatérési értékű 
függvények 

Mit tudtunk tenni SOL7-ben, ha azt kérték tőlünk, hogy kellene 
egy nézet, ami a megrendeléseket listázza ki, de úgy, hogy 
megadhassuk paraméterként, hogy melyik megrendelőhöz tarto- 
zó tételeket kívánjuk látni. Azaz valami ilyesmit akartunk írni: 


CREATE VIEW OrdersByCustomer( 
€CcustomerID varchar(5)) 

AS 

SELECT § FROM Orders 

WHERE 
CustomerID - ECustomerID 


--Nem működik, nem fordul le! 


Nos, ilyen nincs SOL7-ben, sőt SOL2000-ben sem! Ilyenkor 
jön a felmentő sereg, az egy utasításból álló, tábla vissza- 
térési értékű függvény. Az előbbi majdnem működő nézetet 
könnyen átalakíthatjuk egy tábla visszatérési értékű függ- 
vénnyé, ami már az elvárt funkciót valósítja meg: 
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CREATE FUNCTION OrdersByCustomer( 
€CustomerID varchar(5)) 
RETURNS TABLE 
AS 

RETURN ( 

SELECT t FROM Orders 

WHERE 

CustomerID - ECustomerID) 

--Teszt: 
SELECT CustomerID, ShippedDate 
FROM OrdersByCustomer ( " THEBI " ) 


THEBI 1996-09-27 
THEBI 1997-11-o5 
THEBI 1998-01-09 
THEBI 1998-04-03 


Mit kellett tennünk, hogy a majdnem-működő, de azért mé- 
giscsak-ramaty nézetünkből egy jólfésült függvény legyen? 
A CREATE VIEW helyett CREATE FUNCTION-t írunk. Jelezzük, 
hogy a függvény visszatérési értéke nem holmi skalár, ha- 
nem tábla: RETURNS TABLE. Látható, hogy nem specifikál- 
tuk az eredménytábla szerkezetét, csak egyszerűen megad- 
tuk, hogy tábla lesz. Emiatt van, hogy az ilyen típusú függ- 
vényekben csak 1, azaz egy darab SELECT utasítás lehet, hi- 
szen annak az eredményhalmaza határozza meg a visszaté- 
rési értékként generálódó tábla típusát. Pontosabban lehet 
benne egymásba ágyazva több SELECT utasítás is, de a tel- 
jes lekérdezés csak egy eredményhalmazt adhat vissza. Azaz 
pont ugyanaz a helyzet, mint a nézeteknél volt. 


Több utasításból álló, tábla visszatérési értékű függvények 
Bonyolultabb esetben a visszatérési érték nem állítható elő 
egyetlen SELECT utasítás segítségével, ilyenkor kell használ- 
nunk ezt a függvénytípust. Mivel ilyenkor már nem egyértel- 
mű, hogy melyik lekérdezés kimenetét szeretnénk visszaad- 
ni, explicit deklarálnunk kell a visszatérési értékként szolgá- 
ló tábla szerkezetét egy tábla típusú változóként. A változót 
INSERT utasítások segítségével feltöltjük (akárhány lépés- 
ben), és a RETURN utasítás ezt fogja visszaadni a hívónak. 
Erre a függvénytípusra összetettebb példákat a következő 
fejezetben találhatunk. 


Praktikus felhasználói függvények 

Annak örömére, hogy megkaptuk a felhasználói függvénye- 
ket, használjuk ki az alkalmat, és írjuk meg néhány olyan 
probléma megoldását, ami a minden napi fejlesztések so- 
rán sokszor előjött-előjön. 


Szövegelőfordulás számláló 

Gyakori feladat, hogy egy szövegben meg kell keresni azt, 
hogy egy másik szöveg hányszor fordul elő benne. Milyen 
algoritmust használjunk? Az egyik legegyszerűbb, bár nem 
feltétlen a leghatékonyabb módszer az, hogy a keresendő 
szöveg minden egyes előfordulását cseréljük ki egy üres 
sztringre a ,nagy" szövegben (amiben keresünk) , és az ere- 
deti szöveg hosszából vonjuk ki az így kapott szöveg 
hosszát. Ezt az eredményt már csak le kell osztani a kere- 
sendő szöveg hosszával, hisz minden csere után ennyivel 
csökkent az ,nagy" szöveg hossza. Hogy néz ez ki függ- 
vényként? (A bemutatott példa egy nagyon nem normalizált adat- 
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bázis, annyira nincs formában, hogy még 0. normál formában 


sincs. Csak demócélokra szolgál, nem adatbázistervezési minta!) 


CREATE FUNCTION StringOccur 
( 
ecstring AS varchar(8000), 
€cLookFor AS varchar(100) 
) 
RETURNS int 
As 
BEGIN 
RETURN 
(LEN(€cString) 
-LEN(REPLACE(€écString, EcLookFor, "!"))) 
/ LEN(EcLookFor) 
END 
--Teszt tábla 
CREATE TABLE T1l 
( 
cMenu varchar(100) NOT NULL 
) 
--Tesztadatok 
INSERT INTO T1l VALUES( Töltött káposzta, Almáspi 
b te, 
INSERT INTO T1 VALUES( Pulykarizottó, Mákosbejgli, 


Diósbejgli") 


4 Diósbejgli") 
INSERT 
4 ka, 
INSERT 
4 


INTO T1 VALUES( "Székelykáposzta, Rántottbé 
Mákosbejgli" ) 
INTO T1 VALUES( Stefániasült, Káposztáspi 
te, Túrósbejgli") 
SELECT 
cMenü AS Menü, 
dbo.StringOccur(cMenu, "káp") AS 
Káposztásfogás, 
dbo.StringOccur(cMenu, "bejgli") AS 
Bejglitartalom, 
dbo.StringOccur(cMenu, "Mákos") AS 
Mákosfogás 


FROM TI 


A kimenet (nyomdai okokból táblázatban): 


Káposztás — Bejgli Mákos 
Menü fogás — tartalom fogás 
Töltött- Almás- Diós- 
káposzta pite bejgli 1 1 0 
Pulyka- Mákos- Diós- 
rizottó bejgli bejgli 0 É HL 
Székely- Rántott- Mákos- 
káposzta béka bejgli ü 1 Ül 
Stefánia- — Káposztás- Túrós- 
sült pite bejgli 1 1 o 


A függvény elég trükkös, megér néhány szót. , Izomból" 
nekifutva hogyan oldanánk meg a példát? Egy ciklusban 
keresnénk a keresendő szöveg előfordulásait a , nagy" szö- 
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vegben, mindig a következő pozíción (karakteren) folytat- 
va a ,nagy" szövegben, mint ahol az előző lépésben abba- 
hagytuk. Ehhez a megoldáshoz ciklust kellene szerveznünk, 
ami jelentősen megbonyolítaná a megoldást. Ehhez képest 
a fenti függvény sokkal egyszerűbb, hisz a bonyolultabb 
funkcionalitást átadtuk a REPLACE függvénynek. 

Más kérdés, hogy az imént vázolt algoritmus és a fenti algo- 
ritmus más kimenetet ad például a következő szövegekre: 


-A fenti függvény (a LEN-es) 
SELECT dbo.StringOccur( bababababa", "baba" ) 
2 


Ezzel ellentétben, ha lenne egy függvényünk, — bababababa 
ami az imént említett módon működne, akkor  bababababa 
a visszaadott érték 4 lenne, hisz: bababababa 

bababababa 


A kérdés az, hogy átlapolhatják-e egymást a keresendő szö- 
veg előfordulások? Ha nem, akkor jó a fenti függvény, ha 
igen, akkor meg kell írni a másik verziót. Ezt a konkrét fela- 
dat határozza meg. 


Szövegdarabolás 

Visual Basic programozók gyakran keresik a Basic Split 
függvény Transact SOL párját. Mindhiába, mert nincs. A 
Split egy nagyon hasznos függvény, arra való, hogy egy 
szöveget valamilyen határoló karakter mentén feldarabol- 
jon, és a darabokat visszaadja egy tömbben. Segítségével 
egy mondatot feldarabolhatunk szavakra, egy vesszővel el- 
választott listát listaelemekre, satöbbi. 

Mivel nincs ilyen függvényünk, implementáljunk egyet! Az 
első akadály, amibe rögtön beleütközünk az, hogy a TSOL- 
ben nincs tömb típus. Emiatt a függvény kimenete tábla tí- 
pusú kell, hogy legyen, mert skalárban nem tudunk 
visszaadni több elemet. Azaz, írjunk egy olyan függvényt, 
ami a megadott szöveg és az elválasztó karakter ismereté- 
ben szétdarabolja a szöveget, és egy táblában visszaadja a 
szövegkomponenseket. Legyen a visszaadott mező neve 
cStringPart! 


CREATE FUNCTION Split 

( 
€coriginalString AS varchar(8000), 
GcDelimiter char(1)) 
RETURNS €SplitString table 


nID int IDENTITY(1,1) NOT NULL, 
cStringPart varchar(8000) NULL) 

AS 

BEGIN 
DECLARE EnNumberOfDelimiters AS int 
--Számoljuk meg, hány határoló 
--karakterünk van. 
--Használjuk fel az előzőleg megírt 
--szöveg-előfordulás számláló 
--függvényünket. 
SET EnNumberofDelimiters - 
dbo.Stringoccur(écoriginalString, EcDelimiter) 


DECLARE 8i AS int 
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SET 8€i — 0 
--Végigmegyünk az összes szövegdarabon 
WHILE Ci c EnNumberOfDelimiters 
BEGIN 
--A forrásszöveg baloldalából 
--kivágjuk az ott található szöveget 
--a határoló karakterig, 
--és beszúrjuk az eredménytáblába. 
INSERT INTO 
E€splitString 
SELECT 
LEFT(€coriginalString, 
CHARINDEX(€cDelimiter, 
E€coriginalString)-1) 
--Levágjuk a már feldolgozott 
--szöveget, így az elején mindig 
--megtaláljuk a következő darabot. 
SET EcoriginalString -— 
SUBSTRING(GcOriginalString, 
CHARINDEX((cDelimiter, 
ecoriginalString)t1, 8000) 


--Továbblépünk a következő darabra 


SET €i s Git1 
END 
--Az utolsó határoló karakter után 
--még maradt egy darab, azt is 
--szűrjuk be az eredményhalmazba. 
INSERT INTO 

esplitString 
VALUES 

(ecoriginalstring) 
--Összeállt az eredménytábla, ideje 
-evisszaadni azt a hívónak. 
--Itt már nem kell jelezni, hogy mit 
--adunk vissza, mert az már a RETURNS- 
--nél (az elején) megtettük. 
RETURN 

END 


--Teszt 


SELECT 
T1.e 

FROM 
Split("Dec 24,Dec 25,Dec 26,Dec 31",",!") 
AS T1 


--Eredmény: 

nID ecStringPart 
1 Dec 24 

2 Dec 25 

3 Dec 26 

4 Dec 31 


Látható, hogy a függvények egymásba ágyazhatók, éppúgy, 
mint a tárolt eljárások. Ezzel élve nagyon jól átlátható, mo- 
duláris programokat írhatunk az SOL Server-re. 


Spam-re fel! 
Az SOL Server segítségével könnyedén írhatunk körlevele- 


tech.net! 


ket, ha van egy címzett (áldozat) adatbázisunk. A klasszi- 
kus megoldásban kurzort használnánk, és az xp sendmail 
külső tárolt eljárást hívnánk meg egy ciklusban. Azonban 
a kurzorok használata elég körülményes dolog. Keressünk 
egy jóval egyszerűbb megoldást, természetesen a felhasz- 
nálói függvények felhasználásával! A megcélzott függvény 
célja egyszerű: a bemenő paraméterekben meghatározott 
címzettnek elküldeni egy E-mail-t. 


--Létrehozzuk a függvényt 

CREATE FUNCTION SendMail 

( 
GcRecepients AS varchar(200), 
ecsubject AS nvarchar(100), 
(ecBody AS nvarchar(3000) 


RETURNS INT 

BEGIN 
DECLARE énResultCode INT 
EXEC €nResultCode - master..xp sendmail 
€recipients - fcRecepients, 
Csubject 5 EcSubject, 
Cmessage - EcBody 
RETURN EnResultCode 

END 

--Egy teszttábla a ,célszemélyekhez" 

CREATE TABLE SpamTarget 

( 
nID int NOT NULL IDENTITY(1,1), 
cTargetEmail nvarchar(400) NOT NULL, 
cFirstName nvarchar(100) NOT NULL, 
cLastName nvarchar(100) NOT NULL 

) 

--Két áldozat felvitele 


INSERT SpamTarget VALUES 
("Zsolt.Soczotw2ktest1.vodafone.hu", "Zsolt", "Soczó") 
INSERT SpamTarget VALUES 
"Elek", "Cudar") 


( "ECudar€vadmalac. hu" , 


--A levelek elküldése. 
SELECT 
dbo.SendMail(cTargetEmail, 
cFirstName t 
"1 Nyerj 99999999999 Forintot!", 
"Legyél te is milliomos!" ) 
FROM 
SpamTarget 
--Az áldozat által kapott levél: 
From: sglacc 
Sent: Saturday, December 23, 2000 6:08 PM 
To: Zsolt Soczo 
Subject: Zsolt! Nyerj 99999999999 Forintot! 


Legyél te is milliomos! 


Anti-hacking toolkit vO.0 

Utolsó és egyben legbonyolultabb függvényünkben egy ál- 
lomány épség (eredetiség) ellenőrző programot írunk. A 
dupla KV ismét javasolt előtte, mert elég bonyolult lesz. 
A feladat, hogy dolgozzunk ki egy olyan módszert, amely 
segítségével a védendő állományok bizonyos jellemzőit le- 
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tároljuk, majd egy ellenőrző rutint lefuttatva ellenőrizzük, 
hogy a jellemző azonos-e a letárolt, háborítatlan értékkel. 
Ha nem, akkor a megfigyelt állományt egy rosszindulatú 
hacker vagy egy még rosszabb indulatú telepítőprogram 
módosította. A példa kedvéért az állomány méretet hasz- 
náljuk fel az ellenőrzéshez. Ennél sokkal profibb megoldás 
lenne, ha az állományokhoz kiszámítanánk valamilyen el- 
lenőrző értéket (pl. MD5 hash), és ezt tároljuk le az adat- 
bázisban. Így sokkal nagyobb valószínűséggel lehetne je- 
lezni, hogy megváltozott egy állomány. 

Hogyan látnánk neki a feladat megoldásának? Mivel a fájlok 
méretét közvetlenül nem lehet lekérdezni az SOL Serverből, 
kénytelenek vagyunk kinyúlni a szerverből. Ehhez valamilyen 
külső tárolt eljárásra lesz szükségünk. AZ xp cmáshell, ami- 
vel külső parancsokat lehet végrehajtani, szinte kínálja ma- 
gát, hogy bevessük erre a feladatra. Meghívunk egy VBScript 
programot, ami visszaadja a paraméterként megadott állo- 
mány hosszát. A külső parancs futtatásából származó soro- 
kat, azaz a fájl hosszát az xp cmáshell táblaként adja visz- 
sza, aminek az első sora tartalmazza a kívánt eredményt. Ho- 
gyan nyerjük ki ebből a táblából az első sort? Próbáljuk be- 
lerakni egy átmeneti (temporary) táblába, és abból leválo- 
gatni az eredményt. Ez azonban sajnos nem megy, mert 
függvényben nem használhatunk temporary táblát. 
Próbáljuk meg belemásolni az xp cmáshell kimenetét egy 
table típusú változóba. Ez sem megy, mert az INSERT Tábla 
(EXECUTE xp cmdshell...) típusú parancs, (ami egy tárolt 
eljárás kimenetét beszúrja egy táblába) nem megy tábla tí- 
pusú változóval, csak valódi táblával. , Valódi" táblát vi- 
szont nem módosíthat egy függvény. Van ebből kiút? 
Utolsó kapaszkodóként elfeledkezünk az xp cmáshel1-ről, és 
megpróbáljuk felhasználni a külső COM komponensek meg- 
hívására szolgáló függvényeket. És ez bejön! A FilegystemOb- 
ject COM komponens közvetlen meghívásával célba érünk. A 
kódhoz tartozó magyarázatot beleszőttem a kódba, mert kira- 
gadva kevésbé érthető lenne. 


--A fájlméret lekérdező függvény 
--deklarációja. 
CREATE FUNCTION GetFileSize 
ú 
€cFilePath AS nvarchar(4000) 
) 
RETURNS INT 
BEGIN 
DECLARE énFileSize int 
DECLARE éhr int 
DECLARE fobjFileSystem int 
DECLARE €objFile int 
--Hozzunk létre a FileSystemobject- 
--ből egy példányt. 
EXEC éhr - sp OACreate 
"Scripting.FileSystemoObject " , 
CobjFilesystem OUT 1 
--Ha hiba történt egyszerűen visszatérünk 
--egy hibakóddal. Ez azért nagyon csúnya, 
--mert a kód későbbi részeiben 
--bekövetkezett hiba esetén 
--felszabadítatlan objektumok maradnak a 


--memóriában! 
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--Így produkciós környezetben le 
--kell kezelni a hibákat megfelelő módon. 
--Ehhez az sp OAGetErrorInfo külső tárolt 
—-eljárást lehet segítségül hívni. 
IF Ehr c5 0 RETURN —1 
--Meghívjuk a Filesystemobject GetFile 
--nevű metódusát, ami visszatér egy 
--File típusú objektummal. Ezt az 
--8objFile változóban tároljuk el. 
--A hívás paramétere az a fájlnév, aminek 
--keressük a méretét (€cFilePath). 
EXEC éhr - sp OAMethod €GobjFileSystem, 
"GetFile", GobjFile OUT, €cFilePath 
IF 6hr cs 0 RETURN —1 
--A File objektum Size nevű 
--tulajdonságának lekérdezésével 
--megkapjuk a keresett állomány méretét. 
--A kapott szám az ÉnFileSize-ba kerül. 
EXEC éhr - sp OAGetProperty €objFile, 
"Size", eénFileSize OUT 
IF €hr c5 0 RETURN —1 
--Felszabadítjuk a létrehozott 
-- objektumokat. 
EXEC Éhr - sp OADestroy GobjFile 
IF éhr c5 0 RETURN —1 
EXEC Ééhr - sp OADestroy GobjFileSystem 
IF E€hr cs 0 RETURN —1 
--Visszatérünk a kapott értékkel. 
RETURN ÉnFileSize 
END 
--Ebben a táblában tároljuk a fájlokat, 
--és a hozzájuk tartozó méreteket. 
CREATE TABLE FileAuthority 
( 
nID int NOT NULL IDENTITY(1,1), 
cFileName nvarchar(3000) NOT NULL, 
nFileSize int NOT NULL 
) 
--Néhány tesztállomány. A —2-vel jelezzük 
--hogy még soha nem olvastuk ki az adott 
--fájl hosszát. 
INSERT FileAuthority VALUES 
("e:Winntinotepad.exe", -2) 
INSERT FileAuthority VALUES 
("ce:(boot.ini", -2) 
INSERT FileAuthority VALUES 
("e:Intldr", -2) 
INSERT FileAuthority VALUES 
("e:Nio.sys", -2) 
INSERT FileAuthority VALUES 
("e:ntdetect.com", -2) 
--Ezzel a tárolt eljárással 
--töltjük fel a táblázat méret mezőit. 
CREATE PROCEDURE CalculateFileSize 
AS 
UPDATE 
FileAuthority 
SET 
nFileSize - dbo.GetFileSize(cFileName) 


--Futtassuk le. Ettől kezdve van egy 
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—--táblázatunk arról, hogy melyik fájlnak 
--milyen hosszúnak kell lenni. 

EXEC CalculateFileSize 

--Nézzük meg, mit tartalmaz a táblánk! 


--SELECT $ FROM FileAuthority 


FileName FileSize 
c: winntlnotepad.exe 50960 
c:lboot.ini 195 
c:Intldr 214416 
c:Vio.sys o 
c:Intdetect.com 34468 


--Ezzel a tárolt eljárással össze 
--lehet hasonlítani a letárolt és 
--a futtatás pillanatában aktuális 
--állományhosszakat. 
--Csak azokat listázza ki, amelyeknél 
--eltérés van a két érték között. 
CREATE PROCEDURE CheckFileSize 
AS 
SELECT 
nID, 
cFileName, 
nFileSize AS OriginalSize, 
dbo.GetFileSize(cFileName) AS 
CurrentSize 
FROM 
FileAuthority 
WHERE 
nFileSize C5 
dbo.GetFileSize(cFileName) 
--Tesztképpen megváltoztattam a boot.ini 
--fájl hosszát. 
--Ellenőrizzük le! 


EXEC CheckFileSize 


A kimenet: 
nID cFileName  OriginalSize CurrentSize 


2 c:lboot.ini 195 197 


Hoppá, a BOOT.INI-t valaki megváltoztatta! Működik az 
ellenőrző eljárásunk. 


Zárszó 
A cikkben felhozott példák két igen fontos dologra világítanak 
rá. A felhasználói függvények felhasználásával nagyon sok, a 
gyakorlatban felmerülő feladatot oldhatunk meg, amelyeket 
eddig csak átmeneti táblák és kurzorok felhasználásával tud- 
tunk megtenni, általában nagyon bonyolultan, és nehezen ol- 
vasható módon. A másik tanulság, hogy a külső tárolt eljárá- 
sok segítségével sok olyan feladatot is megoldhatunk az SOL 
Server segítségével, amelyeket általában más programnyelven 
megírt programokkal (Visual Basic, stb.) végeztettünk el. 
A következő részben a kurzorokról lebbentem fel a fátylat, 
megnézzük, hogy körültekintő felhasználásukkal a felhasz- 
nálói függvényekhez hasonlóan igen bonyolult feladatokat 
is elég egyszerűen megoldhatunk. 
Soczó Zsolt 
MCSE, MCSD, MCDBA 
Protomix Rt. 
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ASP Suli 
(I. rész) 


Kedves Olvasóink! 

Új sorozatot indítunk útjára: bemutatjuk, milyen lehetősége- 
ket biztosít a Windows NT / 2000 webkiszolgálója, az IIS a 
dinamikus weboldalak, sőt, akár teljes webalkalmazások ké- 
szítéséhez. A jelszó: ASP - azaz: Active Server Pages. A cikk- 
ben található példaprogramok megtalálhatók a [1] címen. 


Egy kis alapozás 

Amikor annak idején a HTML-t kitalálták, még senki sem 
gondolt arra, mi lesz a dolog vége. A HTML hipertext-leíró- 
nyelv eredetileg arra való, hogy segítségével egyszerű do- 
kumentumokat hozzunk létre, amelyek egyes részei esetleg 
hivatkoznak más dokumentumok részeire (ez a hiperhivat- 
"kozás, hiperlink). Az eredeti HTML nyelv a hivatkozásokon 
kívül alig néhány elemet tartalmazott, amelyek különböző 
szintű címsorok, idézetek, esetleg listák létrehozását segí- 
tették. A sors fintora, hogy az Internet megjelenésével ép- 
pen a HTML lett az internetes kommunikáció egyik alapja. 
(Nincs ezen mit csodálkozni: különféle adatok és közöttük 
felépített kapcsolatok leírására volt szükség, és a HTML éppen 
kapóra jött.) A ma használatos HTML persze már jócskán 
több, mint egyszerű dokumentumleíró nyelv - pontosan 
annyi köze van az , ős" HTML-hez, mint a mai dokumentu- 
moknak az akkoriakhoz. Régen az adatok struktúrája képez- 
te az alapot, ma inkább azok megjelenítése. 

Ahogy telt az idő, úgy szivárogtak bele a nyelvbe a tartalmat 
nem, azok megjelenítését annál inkább érintő elemek: képek, 
táblázatok, keretek (framek), színek, méretek, betűtípusok, 
külső objektumok, scriptrészletek és ki tudja még mi minden. 
A HTML 4-es változatát többek között pontosan azért alkot- 
ták meg, hogy valamelyest (újra) szétválaszthassuk a tartal- 
mat a megjelenítéstől, ezzel is csökkentve a HTML oldalak 
kódjában található nem kis káoszt. A tartalom és megjelení- 
tés szétválasztása azóta szinte minden területen hódít, füg- 
getlenül attól, hogy a hálózaton található HTML oldalak nagy 
része a mai napig nem használja ki a HTML 4 lehetőségeit 
(köszönhető ez egyébként a szabványokkal többé-kevésbé ha- 
dilábon álló böngésző programoknak is). 


Mozgásba lendül a kód... 

Az idő múlásával egy másik területen is sokat fejlődött a 
HTML, illetve annak felhasználása. Kezdetben elég volt, ha 
egy dokumentumot létrehoztunk, annak tartalma nem, vagy 
csak ritkán változott. Később felmerült az igény arra, hogy 
a gyakran változó HTML oldalak tartalmát dinamikusan hoz- 
zák létre. Kezdettől két irányvonal létezett, attól függően, 
hogy a kiszolgálóra, vagy pedig a dokumentumot felhaszná- 
ló ügyfélprogramra bízták a feladatot. Ez utóbbi megoldás 
nem biztos, hogy működik (senki sem garantálja, hogy az 
ügyfélprogram képes ezt a feladatot végrehajtani), ráadásul 
több szempontból előnytelen is: ha a cél az, hogy 100 do- 
logból csak egy valami jelenjen meg az ügyfél képernyőjén, 
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felesleges mind a százat elküldeni neki, majd ott kiválaszta- 
ni a szükséges egyet - egyszerűbb, biztonságosabb és ol- 
csóbb, ha már eleve csak a számára érdekes adatok kerülnek 
hozzá. Ehhez viszont a kiszolgálónak kell erőfeszítéseket ten- 
nie. A kiszolgálóoldali megoldások közös tulajdonsága, hogy 
a kiszolgáló mindig kész, feldolgozható HTML kódot küld az 
ügyfélnek - a kód tartalma viszont dinamikus, időről időre 
változik. Magyarán: a cél az, hogy HTML kódot generáljunk. 
A legkézenfekvőbb megoldás az volt, ha kész, teljes progra- 
mokat írtak az egyes feladatok végrehajtására. A programok 
szabványos bemeneten (stdin) keresztül kapták a bemenő 
adatokat, majd a szabványos kimeneten (stdout) továbbítot- 
ták az általuk létrehozott kódot. A webkiszolgáló és a prog- 
ramok közötti kapcsolatot az ún. CGI (Common Gateway In- 
terface) valósította meg, így a programok látszólag a kiszol- 
gáló részeként működtek (és működnek ma is). Ezt a mód- 
szert CGI programozásnak nevezzük, és bár néhány területen 
még ma is használatos, hátrányai miatt lassan kiszorul. 

Mert: mit tehetünk, ha azt szeretnénk, hogy a CGI program 
mostantól más kódot generáljon? Egy: újraírjuk, újrafordít- 
juk és kicseréljük a programot. Brrrr. Kettő: Eleve olyan CGI 
alkalmazást írunk, ami a bemenő adatok segítségével para- 
méterezhető. Sőt, mi lenne, ha a bemenő paraméter egy va- 
lamilyen formában meghatározott parancssorozat, vagy akár 
egy valamilyen nyelven megírt script kód lenne? A CGI prog- 
ram azt értelmezi, végrehajtja, és visszaadja az eredményt - 
ez a megoldás a scriptnek köszönhetően teljesen dinamikus 
és bármire" használható lenne - és az is. Jó példa erre a Perl 
nyelv, ahol a webprogramozás lelke a perl.exe. Bemenete 
egy Perl nyelven írt script, kimenete pedig a kész HTML kód. 


ASP a láthatáron 

A fenti megoldás egy kicsit mégis kényelmetlen: milyen jó 
lenne, ha a HTML oldalak általában statikus részét hagyo- 
mányos módon, akár egy kényelmes WYSIWYG szerkesztővel 
készíthetnénk, és csak a dinamikus részt kellene progra- 
mozni! Az Active Server Pages (ASP) elve pontosan ez: ami- 
kor azt mondjuk, ASP, tulajdonképpen egy HTML kódba 
ágyazott, speciális programozási módszerről beszélünk. 
(Fontos, hogy az ASP nem egy programozási nyelv, hanem 
csak egy keretrendszer). Az ASP oldal végrehajtásakor a 
webkiszolgáló végigszalad az oldal tartalmán, és ha abban 
ASP scriptrészletet talál, végrehajtja. A HTML oldal és a 
script által esetleg visszaadott kódrészletek együttesen ké- 
pezik az eredményt, amit azután az IIS elküld a böngésző- 
nek. Lássunk egy példát: 
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:LXZHTML2CHEADPCTITLE2S/TITLE2€/HEAD2 
LBODY2 
ez 
Response.Write("cCcentersHello World!c/center2") 
sz 
£/BODY2 
S/HTML3 


A HTML kód belsejében található -9o és 902 jelzi az ASP kód 
kezdetét és végét. A köztük található kódrészlet elvileg soha 
nem jut el az ügyfélhez, csakis a kód futtatása során keletke- 
ző kimenet (ami esetünkben a Response.Write() metódusnak 
átadott szövegrész). Az ASP scriptek beágyazásának módjáról 
kicsit később még lesz szó, most lássuk, mi lesz az eredmény: 


XxHTML:CHEADPCTITLE2C/TITLE2€/HEAD2 
LxBODY2 

ScentersHello World!c/center5 
£/BODY2 

£/HTML2 


Az ASP kód által generált kimenet tehát összemosódott a 
HTML kóddal. Ez jó, hiszen ráérünk az oldalt teljes egészé- 
ben elkészíteni egy külső, kényelmes HTML szerkesztővel, 
majd utólag beágyazhatjuk az ASP kódot. 

Egy gondolat az ASP használatáról: mint látható, az ASP az 
IIS webkiszolgáló része. A Windows NT 4.0 Option Pack se- 
gítségével telepíthető Internet Information Server 4.0 (Win- 
dows NT 4.0 Workstation-ön Personal Web Server) már tartal- 
mazza az ASP kezeléséhez szükséges komponenseket, ame- 
lyek a Windows 2000 IIS5 webkiszolgálójában természetesen 
alapértelmezett tartozékok. Ha azt szeretnénk, hogy egy fájlt 
az IIS tényleg ASP oldalként kezeljen, adjunk a fájlnak .asp 
kiterjesztést (ha ezt nem tesszük, a kód végrehajtás nélkül el- 
jut az ügyfélhez, mintha a HTML oldal tartalma lenne). 


Az ASP kódok beágyazása 

Az ASP scripte(ke)t az oldalba több módon is beágyazhat- 
juk. Lássuk mindenekelőtt a HTML szabványnak megfelelő 
módot: 


La HTML3CHEADPCTITLE3£/TITLE3€/HEAD5 

LxBODY5 

CKSCRIPT runat-"server" languagez"vbseript"5 
Response.Write("CcentersHello World!c/center?") 

£/SCRIPT2 

£/BODY5 

£/HTML2 


A SCRIPT HTML elem segítségével tehát ugyanúgy ágyazha- 
tunk be kiszolgálóoldalon futó kódot, mintha ügyféloldali 
scriptet írnánk - csak adjuk meg a runat-"server" attribútu- 
mot. Hasonlóan az ügyféloldali megoldáshoz, természetesen 
kiszolgálóoldalon sem muszály az oldalon belül megírni a 
scriptet, megadhatunk fájlnevet is (src attribútum): 


LxSCRIPT runat-"server" src-"scfile.vbs"5 


Látható, hogy itt elhagytuk a scriptnyelv meghatározását. 
Ebben az esetben a kiszolgáló az alapértelmezett script- 
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nyelvet használja. Ezt két helyen határozhatjuk meg: egy- 
részt, az adott .asp oldal tetejére írt, úgynevezett ASP di- 
rektíva segítségével : 


C$8 Language-VBSceript 32 


Ha pedig ez hiányzik, a kiszolgáló a saját beállításait hasz- 
nálja, amit az adott IIS web vagy virtuális könyvtár tulaj- 
donságai között, a ,Home Directory" oldalon, az , Applica- 
tion Settings" részben található ,Configuration" gombra 
kattintva megjelenő , Application Configuration" dialógu- 
sablak , App Options" oldalán, a , Default ASP language:" 
mezőben állíthatunk be. Egyszerű, ugye? 


LEYETSETTSZTTTT ETTE SEEN 3 
App Mappings. App Options ] App Debugging ] 


Application Configutation 
[7 Enable session state 


Sessiontimeout [20 minutes 


FF. Enable bulfering 
[7 Enable parent path: 


Default ASP language. VBScrpt 
ASP Sciipt timeout: [50 seconds 


5 Az ASP alkalmazás beállításai az IIS-ben 


Ha sikerült megtalálnunk ezt a dialógusablakot, jegyezzük 
meg, hogy jutottunk ide, mert sok más, fontos beállítás is 
itt található. 

Az alapértelmezett kiszolgálóoldali scriptnyelv egyébként a 
VBScript. Ezt a nyelvet ,használja" a korábban már bemu- 
tatott, rövidített formátum is: 


ez 
Response.Write("Ccenter2Hello World!c/center2") 


85 


A c és 902 használata rövidebb és kényelmesebb is, ezért 
cikkünk további részében - hacsak kifejezetten nincs szük- 
ség másra - ezt használjuk. 

Természetesen egy oldalon belül több scriptblokk is szere- 
pelhet. Az ASP oldal tartalmát az IIS elölről hátrafelé ha- 
ladva értékeli ki, beleértve magát a HTML kódot is. Az ASP 
kód által visszaadott kód az eredményben ott jelenik meg, 
ahol maga a script szerepel, például a ... 


£pP1cp2c3 Response.Write("a") $5cps2 


€x8 Response.Write("b") $82cp3:3 


. eredménye , 1a2b3" és nem ,ab123" vagy ,123ab". A 
fenti példában láthatjuk azt is, hogy akár soron belül is ké- 
szíthetünk scriptblokkot (inline script), nem ritka az aláb- 
bihoz hasonló megoldás: 


LINPUT type-"textbox" value—-"c$ -sTxt 8275 
Ezután a szövegmezőben az sTxt változó tartalma jelenik 
meg. Újabb újdonsággal találkoztunk: a c9o után írt — a 


Response.Write rövidítése, tehát a c9o0-"Hello!"9oz egyen- 
értékű a c9oResponse.Write("Hello!") oz sorral. 
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Még egy fontos tudnivaló a több részletben beágyazott scrip- 
tekről: nem tilos az sem, hogy a script ,közepén" egyszer 
csak tiszta HTML kód jelenjen meg. Ilyenkor az úgy viselke- 
dik, mintha a kód része lenne, azaz ha az adott szakaszra rá- 
kerül a vezérlés, az is megjelenik, különben rejtve marad. 


£$ For izl To 10 85 
ZcentersHello World!c/center5 


c Next 85 


A fentiek hatására például a Hello World! felirat tízszer író- 
dik ki, az alábbi kódrészlet pedig a csillagok pillanatnyi ál- 
lásától függően hol ezt, hol azt , mondja" (de sosem egy- 
szerre a kettőt!) : 


€x$ Randomize " €- Fontos, különben nem lenne 
" véletlen! 85 
c$ If Int(Rnd()"10) 5 5 Then 85 
gZcentersKököjszic/center2 
€$ Else 85 
gcentersBobojszac/center2 


c End If 82 


Így nagyszerűen szegmentálhatjuk az oldalt. Ha például 
egy ASP oldalon több minden jelenhet meg, de nem egyi- 
dőben, akkor legjobb, ha HTML szerkesztővel létrehozzuk 
az oldalt, benne az összes opcionális résszel, majd ezeket 
a részeket utólag ,körbeépítjük" scripttel, ami majd eldön- 
ti, hogy az adott szakasz látsszon-e vagy sem. 

Bár a c és a 903 nem szerepelnek a HTML szabványban, mi bát- 
ran használjuk, hiszen ezek a jelek soha nem hagyják el a kiszol- 
gálót. Ha az ASP script által generált kimenő kód HTML-kompa- 
tíbilis, nyugodtak lehetünk abban, hogy mi minden tőlünk tel- 
hetőt megtettünk a szabványos kommunikáció érdekében. 


Ügyfél-kiszolgáló kommunikáció: a HTTP protokoll 

A HTML oldalak számítógépek közötti továbbításához ki 
kellett dolgozni egy adatátviteli szabványt. Ez lett a HTTP, 
azaz Hypertext Transfer Protocol. A HTTP nem más, mint 
egy jól definiált ügyfél-kiszolgáló kommunikáció, amit 
most a jobb megértés kedvéért kicsit ízekre szabdalunk. 

A HTTP kommunikációt az ügyfél kezdeményezi: hálózati kap- 
csolatot létesít a kiszolgálóval és közli vele igényeit: ez a 
HTTP kérés (HTTP Reguest) . A kérésre a kiszolgáló választ küld 
(HTTP Response) , majd az eredeti definíció szerint megszakít- 
ja a kapcsolatot és szükség esetén minden kezdődik elölről. 
A kapcsolat megszakítására eredetileg azért volt szükség, 
hogy a fenntartott, használaton kívüli kapcsolatok ne ter- 
heljék feleslegesen a kiszolgálót. Manapság azonban más a 
helyzet: egy HTML oldalon képek, objektumok tömege le- 
het, így elvileg külön kapcsolatot kell felépíteni először a 
HTML kód, majd később minden egyes beágyazott kép és 
objektum letöltéséhez, és ma bizony éppen az újabb háló- 
zati kapcsolatok létrehozása az, ami túlterhelheti a kiszol- 
gálót (ráadásul ez nem is igazán hatékony). Ezért a HTTP 
1.1 verziójában bevezették a Keep-Alive opciót, amiben ha 
az ügyfél és a kiszolgáló megegyezik, a kapcsolat nem 
bomlik le azonnal (magyarul egy kapcsolat során több kérés 
és válasz is elhangozhat). Ha bárki hibát észlel, természe- 
tesen azonnal bontják a kapcsolatot. Ma már szinte min- 
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den böngésző így próbál kapcsolódni a kiszolgálóhoz, azok 
pedig általában elfogadják ezt a kérést. Alapértelmezésben 
így tesz az IIS is, erről a , HTTP Keep-Alives Enabled" op- 
ció kikapcsolásával beszélhetjük le (ezt az adott IIS web 


tulajdonságlapján, a , Web Site" oldalon találjuk) . 





Default Web Site Properties 


2 2] 
Directory Security] HTTP Headers ]  CustomErors ] Server Estensions  ] 
WwebSite ] Performance ]  ISAPI Fiters ] Home Directoy ]  Documents ] 
Web Site Identification szesszel ET 








Description s 

IP Address f[anUnassigneg] 7] Advanced. 
TCP Port [50 kes 
Connections 

s 

CG LintedTa TT 10 connections 

Connection Timeout 900 seconds 


(7 HTTP Keepálves Enabled 


5 A HTTP Keep-Alive kapcsolója az ábra alján látható 


A HTTP kérés- és válaszüzenet egyaránt három fő részből áll: 
" Parancs, illetve státuszinformáció 

"B Fejlécek, metaadatok 

"8 HTTP tartalom 

Az első részben (ami mindig az első sor) kéréskor a kért pa- 
rancs, illetve annak paraméterei, valamint a verziószám uta- 
zik, válasz esetén pedig a státusz- vagy hibaüzenet kódja és 
leírása. Az ezután következő fejlécek a kapcsolat és a később 
következő HTTP tartalom jellemzőt tartalmazzák, ezek vizsgá- 
latára később részletesebben kitérünk, hiszen ami ügyfél-ki- 
szolgáló kommunikáció és nem a HTML kód része, az valahol 
itt , utazik". Végül a HTTP tartalom, ami válasz esetén maga a 
HTML oldal, vagy mondjuk egy kép tartalma, kérés esetén pe- 
dig - ha van - a kiszolgálónak szánt bemenő adatok tömege. 
A fejléceket a HTTP tartalomtól egy üres sor választja el. Az 
ASP a HTML tartalom dinamikus létrehozása mellett természe- 
tesen lehetővé teszi a fejrészben kapott adatok feldolgozását 
és a válasz fejrészének manipulálását is. 


Az ASP objektummodell 

Az .asp oldalak programozását, a HTTP kommunikáció, a web- 
kiszolgáló egyes szolgáltatásainak elérését külön objektummo- 
dell segíti. Az ASP objektummodelljének minden elemét elér- 
hetjük az .asp oldalak kódjaiból. A későbbiek során mindegyik 
ASP objektumot bemutatjuk részletesen is, most vessünk egy 
röpke pillantást a teljes objektummodellre és annak elemeire. 


LETTEK ela 
Session objektum 


-$ Reguest objektum 7 


kh 
"" Response objektum 





Session objektum 7K 
: ] -p. Reguest objektum "A 
4 IA "e Response óbjaktan" 
Ügyfél 


5 Az ASP objektummodellje 
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Ha a tranzakciós műveletekhez használt ObjectContext ob- 
jektumot nem számítjuk, az objektummodell hat (Windows 
NT 4.0-n öt) objektumból áll. A Windows 2000-ben megje- 
lent új objektum az ASPError, ami egy bekövetkezett hiba 
leírását tartalmazza, az .asp-be ágyazott, saját hibakezelést 
segíti. A Server objektum magát az IIS-t képviseli, néhány 
kiszolgálószintű beállítással és szolgáltatással. Az Applicati- 
on objektum egy webalkalmazást jelképez. A webalkalmazás 
különálló egység, általában egy könyvtárban és annak al- 
könyvtáraiban található .asp kódok összessége, közös objek- 
tumokkal és beállításokkal. A Session objektum egy ügyfél 
és a kiszolgáló között , fennálló" kapcsolatot, munkamene- 
tet jelképez. A ,fennálló" kapcsolatot azért írtuk így, mert 
valójában nem egy kapcsolatról van szó. Az IIS (a háttérben 
cookie-k segítségével) azonosítja a felhasználót és a böngé- 
szőt, így az a böngésző bezárásáig saját munkamenetébe 
térhet vissza. A Reguest objektum egy HTTP kérést jelképez, 
segítségével kódból hozzáférhetünk a kérés minden elemé- 
hez, legyen az HTTP fejléc értéke, a böngészőben tárolt coo- 
kie, vagy kérdőív tartama. A Response objektum pedig érte- 
lemszerűen a kérdésre küldendő választ jelképezi. Természe- 
tesen a Response objektum segítségével sem csak a válasz 
tartalmát, hanem a HTTP protokoll fejrészét is kezelhetjük. 
Egy IIS kiszolgálón belül Server és ASPError objektumból 
egy-egy létezik (utóbbi csak akkor érhető el, ha hiba tör- 
tént) . Application objektum minden webalkalmazás egyedi, 
globális objektuma, Session objektum minden munkame- 
nethez (ügyfélhez) egy jön létre, egyidejűleg tehát több is 
létezhet. Reguest és Response objektum pedig mindig az 
adott kérésre és válaszra vonatkozik, újabb kérés esetén új 
példány jön létre belőlük is. 


Egy HTTP válasz - a Response objektum 

Kezdjük a végén: a Response objektummal, ami egy HTTP 
kérésre adott választ hivatott jelképezni. A Response objek- 
tum legegyszerűbb (és leggyakoribb) alkalmazását már lát- 
hattuk korábban: a Response.Write() metódus segítségé- 
vel állítottuk elő az oldal tartalmát. A Write() használata 
egyszerű: minden, amit paraméterként átadunk neki, beke- 
rül a válaszként visszaküldött adatcsomagba. A Write() me- 
tódusról egyetlen dolgot kell tudni: a kiírt szöveg nem tar- 
talmazhatja a 90: jelsorozatot, helyette ezt kell írni: 9e 
Az ezt tartalmazó szöveget IIS automatikusan visszaalakít- 
ja majd az eredeti formára. 


A válaszpuffer 

Az .asp oldal előállítása természetesen több lépésben tör- 
ténik, az oldalban található scripttől függően előfordulhat 
az is, hogy az oldal tartalmának egy része csak bizonyos vá- 
rakozási idő után áll rendelkezésre. Ilyenkor dönthetünk, 
hogy a már kész tartalmat elküldjük-e az ügyfélnek, majd 
várunk a folytatásra, vagy kivárjuk, amíg a teljes oldal el- 
készül, és csak a munka legvégén küldjük a komplett vá- 
laszt. Ez utóbbi esetben a ,kimenet" egy pufferbe kerül. A 
pufferelés az IIS5-ben alapértelmezésben működik, míg az 
IIS4-ben alapértelmezésben ki van kapcsolva. A Response 
objektum segítségével mi magunk is kezelhetjük a puffert: 
mindenekelőtt, a Response.Buffer property-nek False érté- 
ket adva letilthatjuk, True segítségével pedig engedélyez- 
hetjük a puffer használatát. A pufferelés hatását a bon.asp 
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és boff.asp példaprogramok segítségével mindenki kipróbál- 
hatja. A Clear() metódus kiüríti a puffert (Legyünk óvatosak! 
A , külső" HTML kód is a pufferbe kerül, törléskor az is elve- 
szik!) , a Flush() pedig elküldi azt, ami addig a pufferbe ke- 
rült, majd csak azután törli a tartalmát. E két metódust a 
bflush.asp és bclear.asp példaprogramokban mutatjuk be. 
Az oldal feldolgozását bármikor megszakíthatjuk a 
Response.End() meghívásával. Ha az oldal végrehajtása befeje- 
ződik, természetesen a puffer teljes tartalma az ügyfélhez kerül. 
Ha nyom nélkül szeretnénk befejezni a ténykedésünket, az End() 
meghívása előtt használjuk a Response.Clear() metódust. 


HTTP fejlécek küldése 

A HTTP válasz a tartalom mellett számos HTTP fejlécet is 
tartalmaz. Mi magunk is küldhetünk ilyen fejlécet a 
Response.AddHeader() metódus segítségével: 


cz 
Response.AddHeader ( "MyHeader", "MyData") 
32 


A metódus két argumentuma a fejléc neve és értéke - termé- 
szetesen a fentinél értelmesebb célra is felhasználhatjuk. Szá- 
mos dolog van, ami közvetlenül programozható a Response 
objektumon keresztül és végső soron egy-egy HTTP fejléc el- 
küldéséhez vezet (a Response.ContentType property beállítása 
pl. egy , Content-Type" HTTP fejlécet küld, stb.), de előfordul- 
hat, hogy olyasmit kell használnunk, ami nincs így ,kivezet- 
ve". A pufferelés befolyásolja a HTTP fejlécek használatát, ki- 
kapcsolt puffer esetén HTTP fejlécet természetesen csak az ol- 
dal tartalma előtt küldhetünk, tehát a Response.AddHeader() 
metódus ekkor csak az .asp oldal elején (az ASP direktívák 
után) állhat. Fontos tudni, hogy egy fejléc már nem vonható 
vissza: amit egyszer létrehoztunk, az a válaszban már benne 
lesz, még akkor is, ha töröljük a válaszpuffert. 


Tartalom és karakterkészlet 

A HTTP válasz sokféle tartalmat hordozhat magában. Egyál- 
talán nem egyértelmű például, hogy egy HTML dokumentum 
milyen karakterkészlettel íródott. Sőt, még az sem biztos, 
hogy a válasz egy HTML oldal. 

Response.Charset - az oldalban használt karakterkészlet, 
kódtábla. Ha normális magyar betűket is használni szeret- 
nénk, állítsuk ,ISO-8859-2"-re. Természetesen ugyanezt 
HTML-ből, a cMETA: elem segítségével is megtehetjük, az 
alábbi két példa tehát egyenrangú (habár a fejlécben beál- 
lított karakterkészlet általában felülbírálja a HTML-ben meg- 
határozottat — ez a böngészőn múlik): 


cz 
Response.Charset - "ISO-8859-2" 
85 


-ZHTML3CHEAD5 
cmeta http-eguivs"Content-Type" 


4 content-"text/html; charset-ISO-8859-2"5 
£/HEAD5 


Response.ContentType - a válasz MIME típusa (a tartalom 
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típusa). HTML (és .asp) oldal esetén az értéke ,.text/html", 
ha nem állítjuk be, ez az alapértelmezés is. Ennek a jellem- 
zőnek az értékét akkor érdemes módosítani, ha a visszakül- 
dött tartalom nem HTML, hanem mondjuk egy képfájl, 
mint alább (sendpic.asp): 


báj 
Set osStream — 
GW — Server.CreateObject("ADODB.Stream") 
oStream.Type - 1 ! adTypeBinary 
ostream.Open 


oStream.LoadFromFile(Server.MapPath("ms.jpg")) 


Response.ContentType - "image/jpeg" 
Response.BinaryWrite( oStream.Read ) 
sz 


A fent használt Response.BinaryWrite() metódus hason- 
ló a .Write()-hoz, a különbség csak annyi, hogy ez binári- 
san, minden megkötés és konverzió nélkül írja a kimenet- 
re az adatokat. A Server objektum MapPath() metódusáról 
később lesz szó, a lényege az, hogy egy relatív fájlnévből 


Érdemes megfigyelni az előző példaprogramot. Az ott használt 
ADODB.Stream objektum segítségével binárisan is írhatjuk/ol- 
vashatjuk a fájlokat, vagy más adatokat (természetesen adat- 
bázis-mezőket is), míg a FileSystemObject objektum egyelőre 
csak szövegfájlok kezelésére képes. A Stream objektum az ADO 
2.5-ös változatától létezik, ezért előfordulhat, hogy használa- 
ta előtt telepítenünk kell a Microsoft Data Access Components 
(MDAC) legújabb verzióját, ami letölthető a [2] címről. 


Egy nálunk még - sajnos - elhanyagolt jellemző maradt 
utoljára: a Response.Pics jellemző értéke jelezheti, hogy 
egy adott oldal milyen mértékben és mennyiségben tartal- 
maz erőszakra, szexre, meztelenségre és csúnya nyelvre 
utaló ,jeleket". Ha ez az úgynevezett PICS-Label (ami 
egyébként nem más, mint egy speciális HTTP fejléc) utazik az 
oldallal, a szűrők képesek lennének kiválogatni a gyerek- 
szobába nem való tartalmat - ismétlem, ehhez az kellene, 
hogy minden webkiszolgáló összes tartalmát minősítse va- 
laki. 

Ez az IIS beállításoknál egyébként webhelyenként, könyv- 
táranként, vagy akár fájlonként is beállítható: 


Content Ratings MENEEE . ad 
Ratng Service. Ratings 


7 [7 Enable Ratings for this resource 


! 
I ua To setthe rating value assigned to this resource, select the 
category and move the slider bar. 






Category: ASAG 
! 0 
6 Sex 
] 60 Nudity 
I 6-0 Language 
] 
! Rating ————— ——  jF — 


Level 3: Kiling with blood and gore 


5 Egy weboldal PICS-minősítése 
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Visszatérve az ASP-hez, a fenti beállítást kódból a követ- 


kező módon érhetjük el: 


cz 

Response.Pics( "PICS-1.O ""http://ww.rsac.org/ 
4 ratingsvOl.html"" 1 by ""[(mICKJ"" on ""2001. 
4 01.O8T21:2640100"" exp ""2002.01.0O8T12:00 
BY 40100" r(v3s50n0010))" ) 


sz 


Így belegondolva, talán mégis egyszerűbb, ha a grafikus 
felületen beállítjuk :-) 


HTTP státusz és átirányítás 

Response.Status -— A HTTP válasz státuszüzenetét (ami, ha 
minden rendben ment, 200 OK) módosíthatjuk itt. A stá- 
tuszüzeneteket a HTTP szabvány definiálja, és mivel a leg- 
több funkció más módon is elérhető a Response objektu- 
mon keresztül, ezt a megoldást viszonylag ritkán használ- 
juk. Hogy mégse maradjunk példa nélkül, lássunk egy 
átirányítást (red0.asp): 


ez 
Response.Status - "302 Object Moved" 
Response.AddHeader "Location", 

b "http://ww.microsoft.com" 


45 
A fenti kódrészlet egyenrangú az alábbival (red1.asp): 


ez 
Response.Redirect( "http: //www.microsoft. com" ) 
sz 


A Response.Redirect() metódus tehát az ügyfél kérésének 
azonnali átirányítására való. A 302-es kódú HTTP üzenetnek 
(tehát az átirányításnak) egyetlen hátránya van: néhány 
proxy bizonyos körülmények között nem hajtja végre az au- 
tomatikus átirányítást, hanem ronda , Object moved" hiba- 
üzenetet küld vissza a böngészőbe. Ez akkor következhet be, 
ha az átirányítás mellett az adott oldal HTML tartalommal is 
bír (magyarul, ha a válaszban nem csak az átirányító fejlécek 
szerepelnek, hanem más is). Három megoldás kínálkozik: 

"B Redirect() előtt ürítsük ki a puffert (Clear() metódus), 
vagy eleve ne írjunk bele semmit (a Redirect() az oldal 
elején szerepeljen) 

"8 Ha kiszolgálón belül kell , átirányítani", akkor használ- 
juk inkább a Server objektum Transfer metódusát 
(IIS5-től), ami kiszolgálón belüli átirányítást végez 
anélkül, hogy az ügyfél erről tudomást szerezne 

"8 Használjuk a HTML-ben gyakori átirányítási módszert, 
ilyenkor maga a böngésző kezd automatikus letöltés- 
be, ami ráadásul időzíthető: 


CMETA http-eguiv-"refresh" 


b content-"O;URL-http://www.microsoft.com/"5 


A fenti példában az időzítés 0, azaz a böngésző azonnal 
belekezd az új cím letöltésébe. A cMETAs elemet a HTML 
oldal fejrészébe helyezzük el (ld. red2.asp). 
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Van itt valaki? 

Ha egy oldal előállítása sokáig tart, vagy a webkiszolgáló 
túlterhelt, előfordulhat, hogy a kérés kiszolgálása közben 
(vagy előtt) az ügyfél megunja a várakozást és továbbáll. 
Az ilyenkor elvégzett munka kárba vész - még szerencse, 
hogy szükség esetén ellenőrizhetjük, nem hiába dolgozunk- 
e. Ha a Response.IsClientConnected property értéke ha- 
mis, nyugodtan befejezhetjük a feldolgozást, ha viszont 
igaz, érdemes még dolgozni. Természetesen felesleges min- 
den sor előtt ellenőrizni, általában csak hosszú végrehajtá- 
si idejű oldalaknál van erre szükség, akkor is csak időközön- 
ként - nehogy többe kerüljön a leves, mint a hús. 

Az IIS5 olyan komolyan veszi ezt, hogy minden kérés feldolgo- 
zása esetén ellenőrzi, hogy a kérés mennyi ideje érkezett. Ha a 
kiszolgáló túlterhelt, és a kérés több mint három másodperce 
várakozik, ellenőrzi, hogy megvan-e még az ügyfél, és csak ak- 
kor kezd bele a végrehajtásba, ha van kinek elküldeni a választ. 


Az IIS4 kicsit felemás módon viselkedik az .IsCtientConnected 
jellemző kiértékelésekor. Ha az oldalunk ilyen kiszolgálón fut, 
tudnunk kell, hogy az .IsClientConnected csak akkor használ- 
ható biztonságosan, ha az oldalból valamit már elküldtünk 
az ügyfélnek (ha például a pufferelést bekapcsoltuk, csak a 
Flush() meghívása után számíthatunk helyes eredményre). 


Gyorsítótárak minden szinten - a cache 

Mi lenne velünk, ha nem lennének gyorsítótárak? A hálóza- 
ti kapcsolatok lelassulnának, áruk az egekbe szökne (igen, 
lenne még hova :-) ), az Internet-szolgáltatók bedugulná- 
nak. (Felszabadulna néhány száz megabájt a merevlemezün- 
kön :-) ). Ez senkinek sem lenne jó. Még szerencse, hogy 
ugyanarra a tartalomra sokan, sokszor kíváncsiak, és nem 
szükséges a dolgokat újra és újra létrehozni és letölteni az 
eredeti származási helyükről. 

Gyorsítótárat alkalmaz a böngészőnk, saját gyorsítótárból dol- 
gozik az Internet-szolgáltató, úgynevezett reverse-cache se- 
gíti a webkiszolgálókat a kérések gyors kiszolgálásában. Álta- 
lánosságban elmondhatjuk, hogy - szerencsére - aki tud, tar- 
talékolja a dolgokat, hátha később még szükség lehet rá. 
Ezzel általában nincs is baj, de lehetnek dolgok, amelyeket 
felesleges elmenteni, mert a nevük, esetleg méretük hiába 
változatlan, tartalmuk gyakran eltérő. Kell-e jobb példa er- 
re, mint a dinamikusan létrehozott weboldalak? Ugye, nem? 
Szerencsére a gyorsítótárak többsége távirányítható - a 
tartalom önmaga hordozhat olyan jeleket, amiket felismer- 
ve a gyorsítótár nem próbálkozik a tárolásával. Ilyen , jelek" 
(természetesen HTTP fejlécek) létrehozásában segít nekünk 
a Response objektum alábbi néhány szolgáltatása: 
Response.CacheControl - Az oldal tárolásának szabályai. Ha 
értéke , private", akkor proxy kiszolgálók nem, csak és kizá- 
rólag privát, böngészőbeli gyorsítótárak tárolhatják az ada- 
tokat. Ez az alapértelmezés is. Ha a jellemző értéke , public", 
akkor az oldalt bármelyik proxy kiszolgáló tárolhatja. Ha azt 
szeretnénk, hogy egyáltalán senki ne tárolja az oldalunkat, a 
property-nek adjuk ezt az értéket: ,no-cache". 
Természetesen semmi sem tart örökké: még ha tárolunk is 
valamit, időnként érdemes frissíteni. Minden tárolt tarta- 
lomnak van egy ,lejárati ideje", amit mi magunk állíthatunk 
be a Response.Expires és Response.ExpiresAbsolute jel- 
lemzők segítségével. Az előbbi az adott pillanattól szá- 
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mított lejárati időt jelenti (percben), míg az utóbbinak 
konkrét időpontot adhatunk meg, pl.: 


c Response.ExpiresAbsolute- 
§,  §May 31,2001 13:30:15$ 35 


Az oldal tárolását elkerülhetjük úgy is, ha a lejárati időt 
-1-re állítjuk: 


c Response.Expires 5 -1 85 


Régebbi, a HTTP 1.1 szabvánnyal nem kompatíbilis kiszol- 
gálók nem értelmezik a CacheControl értékét, ezért néha 
speciális HTTP fejlécre van szükség: 


c$ Response.AddHeader "Pragma", "no-cache" 85 


A legbiztonságosabb természetesen az, ha mindhárom mód- 
szert (CacheControl, Expires, Pragma) kombináljuk. Ha nem 
akarunk ASP-t használni, ezt a szokásos módon, cMETAz 
elemek segítségével tisztán HTML-ből is megtehetjük: 


LxMETA HTTP-EOUIV-"CacheControl" 

3  CONTENT-"no-cache"5 

LxMETA HTTP-EOUIV-"Pragma" CONTENT-"no-cache"5 
LxMETA HTTP-EOUIV-"Expires" CONTENT-"-1"5 


HTTP kérés - a Reguest objektum 

Adatküldés a HTTP protokoll segítségével 

A dinamizmus, az interaktivitás egyik mozgatórugója természe- 
tesen az, ha menet közben adatokat kapunk az ügyfél oldaláról. 
Ezeket az adatokat a Reguest objektum segítségével érhetjük el. 


Adatok átadása az URL-ben (OueryString) 
A klasszikus adatbeviteli módszer, amikor az adatokat a ké- 
rés URL-jéhez csatoljuk, ilymódon: 


http://localhost/gs.asp?inputl-vallainput2-val2 
Ekkor ilyen HTTP kérés indul a kiszolgáló felé: 


GET /reguest.asp?inputl-valuelginput2-value2§ 
4 submitsSubmit HTTP/1.1 


Ennek a módszernek több hátránya is van: egyrészt, a be- 
menő adatok növelik az URL hosszát, a kiszolgálónak el- 
küldhető URL-ek mérete pedig biztonsági okokból általá- 
ban korlátozva van. (Próbáljunk meg az IIS-nek elküldeni 
egy többszáz bájt hosszú címet! - A válasz szabványos HTTP 
hibaüzenet: , 404 - Reguest - URI too long"). Másrészt 
nemcsak kényelmetlen, de nem is igazán biztonságos, 
hogy az átadott adatok (amelyeket esetleg nem is mi írtunk 
be, hanem mondjuk egy kérdőív rejtett részei voltak) meg- 
jelennek a böngésző címsorában. 

Az átadott adatmezők névzadat formájúak (ld. fent: 
input1-val1), az egyes adatmezőket 8. jel választja el egymás- 
tól, az egészet pedig kérdőjel a fájlnévtől. Egy adott mező ér- 
tékét a Reguest.OueryString(, mezőnév") függvény adja vis- 
sza. Ha az adatok között ilyen mező nem szerepel, a visszaadott 
érték (,,). A gs.asp fájl az alábbi kódrészletet tartalmazza: 
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cz 
If Len( Reguest.OueryString("nev") ) Then 
Response.Write( "Szia " § 
4 Reguest.OueryString("nev") a "!" ) 
End If 
32 


Ha nevünket megadjuk az URL-ben (pl. gs.asp?nevzmick), 
akkor az oldal illendően köszönt minket. Egy mező ,meg- 
létét" a legegyszerűbben úgy ellenőrizhetjük, ha lekérdez- 
zük a hosszát (ezt teszi a Len() függvény a példában). Ha 
ez nem 0, lehet dolgozni. 

Egy mezőnek azonban nem csak egy értéke lehet, a HTTP 
kérésben egy mezőnév egynél többször is szerepelhet: 


http: //localhost/gs2.asp?nev-Piroskagnev-Farkas 


A gs2.asp fájlban látható, hogyan lehet ezt feldolgozni: 


cz 
Response.Write("Nevek száma: " § 
4 Reguest.OueryString("nev").Count § "cbr2") 
For i-1l To Reguest.OueryString( "nev" ) .Count 
Response.Write( i a ": " § 
4 Reguest.OueryString("nev")(i) § "cbr2") 
Next 
32 


A Reguest.OueryString(, mezőnév") .Count érték visszaad- 
ja az adott nevű mezők számát. Ha a sok közül egy konkrét 
értékre vagyunk kíváncsiak, akkor átadhatjuk az indexet is 
(a számozás 1-től kezdődik). Maradjunk a fenti példánál, a 
Farkas-ra így hivatkozhatunk: 


Reguest.OueryString( "nev" ) (2) 


Ha egy mezőnek több értéke van, és mi mégis közvetlenül 
kérdezzük le (pl. Reguest. 0ueryString(,, nev") ) , akkor az ér- 
tékek vesszővel elválasztott listáját kapjuk válaszként: ,Pi- 
roska, Farkas". Ha pedig egyszerűen csak Reguest.OueryString- 
re hivatkozunk, akkor visszakapjuk a teljes kérdést: 
,Nnev-Piroskagnev-Farkas". 

Ez volt tehát az URL-be ágyazott lekérdezés feldolgozása. 
Egy fontos és sokszor zavaró tényezőre még szeretném fel- 
hívni a figyelmet: az URL-ek formátuma kötött, és mivel a 
lekérdezés (és főleg az átadott adatok) ilyenkor az URL ré- 
szét képezik, ezeknek az adatoknak is meg kell felelniük bi- 
zonyos szabályoknak: például, minden írásjel, neadj" Isten 
ékezetes karakter csakis kódolt formában (pl. egyenlőség- 
jel: 930) szerepelhet az URL-ben. Ez a kódolás pedig sok- 
szor körülményes és kényelmetlen. 


Adatfeltöltés a POST HTTP paranccsal 

Szerencsére a HTTP protokoll tartalmaz egy, a fentinél fejlettebb 
megoldást is. A POST parancs használata esetén a feltöltendő 
adatok a HTTP üzenet törzsrészébe kerülnek. Az adatok kódolá- 
sát persze így sem ússzuk meg, de az esetek többségében ezt a 
munkát nem mi, hanem a böngésző végzi. Kérdőív (Form) kitöl- 
tése esetén például, ha a FORM elem method attribútumát post- 
ra állítottuk, a következő kérés indul a kiszolgáló felé: 
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POST /reguest.asp HTTP/1.1 

Content-Type: application/x-www-form-urlencoded 
Content-Length: 41 

Connection: Keep-Alive 


inputlsvaluelginput2svalueZssubmit-Submit 


Láthatjuk, hogy a kiszolgálónak szánt adatok nem a POST 
parancs paraméterében, hanem a HTTP üzenet törzsrészé- 
ben utaznak. Érdemes megfigyelni a törzs kódolására vo- 
natkozó Content-Type HTTP fejléc értékét is. 


És itt álljunk meg egy szóra! Aki ismeri a HTML nyelvet, az 
tudhatja, hogy a HTML kérdőív elemének (FORM) method att- 
ribútuma határozza meg az adatok küldésének módját. Ha a 
method attribútum értéke , get", a kérdőív tartalmát az URL- 
be ágyazva, ha viszont az attribútum értéke ,, post", akkor a 
HTTP kérés törzsében küldi el a böngésző a kiszolgálónak. A 
form.asp példaprogrammal bárki kipróbálhatja a különbsé- 
get. Lehetőség szerint használjuk tehát a post módot! 


A kérdőív egyes mezőinek értékét a Reguest.Form kollekció 
tartalmazza. Az előző példához hasonlóan minden mező ér- 
tékét lekérdezhetjük, ha a mezőnek több értéke van, akkor itt 
is használhatjuk a .Count jellemzőt és az indexeket is, pl.: 


Reguest.Form( "nev" ) 
Reguest.Form( "nev" ) .Count 


Reguest.Form("nev") (5) 


Érdekesség: Kérdőív feldolgozása esetén a Submit nyomó- 
gomb értéke (felirata) is eljut a kiszolgálóhoz, de ha több 
ilyen van, akkor csak annak az egynek, amelyikre kattintot- 
tunk. Így megtehetjük azt, hogy ha egy kérdőívbe két Sub- 
mit nyomógombot teszünk: 


LINPUT type-"submit" namez"submit" valuez"Egyél": 


LINPUT typesz"submit" namez"submit" valuez"Igyál"5 


... a feldolgozáskor könnyen kitalálhatjuk, 
mit szeretne a kedves ügyfél: 


ez 
If Reguest.Form("submit") - "Egyél" Then 
" Eszem 
Else 
" Iszom 
End If 
sz 


A For Each utasítás segítségével (a többi kollekcióhoz hasonlóan) 
a .Form kollekció elemeit is kilistázhatjuk (ld. reguest.asp): 


ez 

For Each mezo In Reguest.Form 
! a mezo-be a mezonev kerul 
Response.Write( "cb5" § mezo §£ " -— €/b5" a 
3, Reguest.Form(mezo) §£ "cbr2" ) 

Next 
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DEVELOPER ASP SULT (I. RÉSZ) 

A HTTP tartalom kiolvasása 

Nem kötelező a Reguest objektum kollekcióira támaszkod- 
nunk, ha ki szeretnénk olvasni a HTTP kérés törzsében el- 


küldött adatokat: 


ez 

bytes - Reguest.TotalBytes 

data - Reguest.BinaryRead(bytes) 
sz 


A Reguest.TotalBytes jellemző visszaadja a törzsben talál- 
ható adatok méretét, a Reguest.BinaryRead() metódus pe- 
dig adott mennyiségű adatot olvas be, természetesen min- 
den átalakítás és konverzió nélkül. 

Fontos! A Reguest.BinaryRead() metódus használata 
után már nem használhatjuk a Reguest.Form kollekciót, 
és fordítva: ha a Reguest.Form-hoz már ,hozzányúltunk", 
a Reguest.BinaryRead() már hibát okoz. 


Cookie 

Szüleink azt tanították, hogy idegenektől ne fogadjunk el 
édességet. Én most mégis azt mondom, ebben az egy eset- 
ben kivételt tehetünk. A cookie kis adatcsomag, amit a ki- 
szolgáló kérésére a böngésző az ügyfél számítógépén tárol, 
és szükség esetén visszaküldi azt. 

Alapjában véve két különböző típusú cookie létezik: az első tí- 
pus csak addig ,él", amíg a böngészővel egy kiszolgálónál tar- 
tózkodunk. A böngésző bezárásával az ilyen cookie tartalma el- 
veszik. Ezeket a cookie-kat elsősorban átmeneti célra használ- 
juk (például az ASP Session fenntartására). A másik fajta, fel- 
használói szemmel gyakrabban megfigyelt cookie annyiban kü- 
lönbözik az előzőtől, hogy a böngésző bezárásakor nem veszik 
el, hanem a számítógép lemezére kerül. Az ilyen cookie-knak 
érvényességi idejük van. Amíg ez az érvényességi idő le nem 
jár, addig a böngésző megőrzi az értéküket, és tartalmukat 
minden egyes látogatáskor visszaküldi a kiszolgálónak. A két 
cookie-fajtát csak a lejárati idő különbözteti meg egymástól. 
Lássuk tehát, hogyan küldhetünk egyszerű, átmeneti célra 
használható cookie-t a böngészőnek: 


zt 
Response.Cookies("nev") - "ertek" 
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Ha a felhasználó legközelebb felénk jár, ezt az adatot így 
olvashatjuk ki: 


báj 
s - Reguest.Cookies("nev") 


35 


Egy cookie nem csak egy szöveget tartalmazhat, hanem 
többet is, egyfajta táblázatot, almezőket: 


cz 


Response.Cookies("nev")("mezol") - "ertekl" 
Response.Cookies ("nev") ("mezo2") - "ertek2" 


sz 


A .HasKeys metódus segítségével eldönthetjük, hogy egy 
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cookie egyszerű szöveg, vagy almezők gyűjteménye, és et- 
től függően kezelhetjük is: 


cz 

If Reguest.Cookies("nev").HasKeys Then 

For Each mezo In Reguest.Cookies("nev") 
Response.Write( Reguest.Cookies("nev") (mezo) ) 

Next 

Else 
Response.Write( Reguest.Cookies("nev") ) 

End If 


32 


A .HasKeys elérhető a Response objektumon keresztül is. 
Erre azért van szükség, mert ha egy szöveges típusú cookie- 
ban almezőket hozunk létre, elveszik a szöveges érték - és 
fordítva, ha almezőkkel rendelkező cookie-nak szöveges ér- 
téket adnánk, elvesznének az almezők és azok értékei. 

A cookie érvényességét a Response objektum segítségével 
korlátozhatjuk időben és ,térben": 


cz 
Response.Cookies("nev").Expires - "01-Jan-2003" 
Response.Cookies("nev") .Domain — 
4 " netacademia.net" 
Response.Cookies("nev").Path - "/dirl/dir2" 

85 


Az .Expires jellemző értéke határozza meg, hogy az cookie 
meddig marad életben. Ha nem adjuk meg, a böngésző le- 
zárásakor elveszik. A .Domain jellemző segítségével beállít- 
hatjuk, hogy a böngésző milyen domainek elérése esetén 
küldje vissza a cookie-t. A .Path pedig kiszolgálón belüli 
részletezést jelent: ha két azonos nevű cookie létezik, 
ugyanarra a domain-re, akkor annak az értékét fogjuk 
visszakapni, ahol a .Path értéke közelebb van a valósághoz. 
Ha tehát az oldal a /dir1/dir2 könyvtárak mélyén található, 
a két cookie .Path értéke pedig a /dir1 és a /dir1/dir2, ak- 
kor az utóbbit fogjuk viszontlátni. 

Ha azt szeretnénk, hogy egy cookie az adott pillanattól számí- 
tott egy évig legyen érvényes, használjuk a DateAdd() és a Now 
függvényt: 


cz 
Response.Cookies("egyevigjo") .Expires -— 
8, DateAdd( "yyyy", 1, Now) 
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Fülöp Miklós 
mickonetacademia.net 


A cikkben található URL-ek: 


[1] http://technet.netacademia.net/feladatok/asp/1 
[2] http://www.microsoft.com/data 


ASP objektummodell-referencia a weben: 
http://msdn.microsoft.com/librai 
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Bevezetés 
A vállalatoknak biztosítaniuk kell alkalmazottaiknak a vál- 
tozások és lehetőségek azonnali felismerését, és az azokra 
való gyors válaszadást, hogy alkalmazkodni tudjanak a vál- 
tozó viszonyokhoz. 
A sikeres vállalatok ezt az információ megosztásával érik el, ezért 
szükségük van olyan eszközökre, melyek elősegítik az elgondolá- 
sok, a folyamatok és a rendszerek megértését. Ez különösen akkor 
igaz, ha a rendszerek túl összetetté válnak ahhoz, hogy szavakkal 
egyszerűen leírhatók legyenek. A számítógépes hálózatok leírása 
például elképzelhetetlen lenne ábrák nélkül. 

Ez a cikk egy új vállalati kommunikációs módszert mutat be, 

melyet a Microsoft vizuális munkamódszernek (visual workstyle) 

nevez. Bemutatjuk, hogyan válnak jobban érthetővé az össze- 

függések, és hogyan javítható a kommunikáció a Visio 2000 

(mely az egész világon szabványként elismert üzleti célú rajzoló 

és ábrakészítő program), a vizuális munkamódszer megvalósí- 

tási eszközének vállalati szintű bevezetésével. Látható lesz, 
hogy a Visio 2000-ben megtalálható a hatékony vizuális kom- 

munikációs eszközök négy fő jellemzője. A Visio 2000: 

0 Alkalmazkodóképes. A világ nagyvállalatainak szembe 
kell nézni a globalizáció, az egybeolvadás (például 
Daimler és Chrysler), a felvásárlás (például Microsoft és 
Visio :) ), a távoli és mobil munkaerő és a túlzott 
mennyiségű információ okozta kommunikációs kihívá- 
sokkal. Ezeknek a vállalatoknak olyan eszközökre van 
szükségük, melyek biztosítják a piaci változásokra és 
munkahelyi problémákra való gyors reagálást. A vizuális 
munkamódszer a természetadta emberi tulajdonságokon 
alapul, és a megfelelő eszközök használatával nagyon 
hatékonnyá tehető. 

"0 Rugalmas. A sikeres vállalatok megértették, hogy a ver- 
senyelőny biztosításának kulcsa az, hogy az elgondolá- 
sokat, folyamatokat és rendszereket az alkalmazottaik 
gyorsan megértsék, és ezzel biztosítva legyen számukra 
a nagyobb hatékonyság és a hibátlan munkavégzés. Ezek 
megvalósításához rugalmas eszközökre van szükség. 
Programozható. A versenyelőny és alacsony működési 
költség biztosításához olyan platformra van szükség, 
mely a lehető legtöbb "dobozból kivett" eszköz felhasz- 
nálásával biztosítja gyorsan üzembe helyezhető és jól 
testreszabott alkalmazások készítését. A Visio 2000 jól 
átgondolt fejlesztői platform, mely az egyedi megoldá- 
soknak jó alapot biztosít. 

B Költséghatékony. A vállalatok egyre több pénzt költe- 
nek az informatikai infrastruktúra felépítésére és kar- 
bantartására. Az átgondoltan építkezők olyan eszközö- 
ket keresnek, melyek beépülnek a meglévő rendszerek- 
be, és képesek együttműködni azokkal, így csökkentve 
a teljes birtoklási költséget. 
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Az új vizuális munkamódszer 

A mai üzleti viszonyok rákényszerítik a vállalatokat a piaci 
változásokhoz való azonnali alkalmazkodásra. Ehhez szük- 
ség van a megfelelő rendszerek birtoklására, melyek lehető- 
vé teszik az akár világszintű hálózatra kiterjedő reakciókat. 
A szellemi munkásoknak képesnek kell lenni a változások 
gyors megértésére és kezelésére, valamint olyan eszközök- 
kel kell rendelkezniük, melyek biztosítják számukra az új le- 
hetőségek felismerését és kihasználását. A vizuális munka- 
módszer a folyamatos változások közben létrejövő informá- 
ciók megértésének és megosztásának az emberek képessé- 
geihez legjobban alkalmazkodó, intuitív módja. 

Ebben a részben a vállalati kommunikáció és tanulás legna- 
gyobb kihívásait ismertetjük, és bemutatjuk, hogyan alakít- 
hatják a szellemi dolgozók vizuális munkamódszer segítsé- 
gével ezeket a kihívásokat lehetőségekké. 


Kommunikációs kihívások 

A munkamódszerek változása. A vállalati hatékonyság előtér- 
be kerülése a vállalati vezetés struktúrájának ellaposodásá- 
hoz, és az önállóan dolgozni képes munkaerő iránti igény 
megnövekedéséhez vezetett. Emellett a munkahelyi struktú- 
rák is megváltoztak. 30 százalékkal több munkát végeznek ma 
a munkacsoportok, mint tíz évvel ezelőtt, a megbeszéléseken 
való távoli részvétel pedig mintegy 25 százalékkal nőtt. 

Túl sok információ. A szellemi munkásokat folyamatosan 
bombázzák információkkal (általában szöveges dokumentumok- 
kal), ezért ritkán van idejük a megszerzett információk 
megosztására, vagy egy saját tudásbázis kialakítására és bőví- 
tésére. A vezetők fele érzi úgy, hogy gyakran képtelen a meg- 
kapott információmennyiség kezelésére, és 43 százalékuk arra 
panaszkodik, hogy fontos döntések meghozatala csúszik, mert 
csökken a döntéshozó képességük a túl sok információ miatt. 
Az Internet térhódítása. Óvatos becslések szerint is több mint 
160 millió ember kapcsolódik az Internetre. Az Internet és az 
intranetek a munkatársak és az ügyfelek közti hatékony kom- 
munikációs, és kapcsolatépítési lehetőségeket biztosítanak, de 
rengeteg információ keveredik rajtuk össze, melyek egy részét 
a dolgozóknak meg kell jegyezni, és hogy dolgozni tudjanak ve- 
lük, osztályozniuk kell, és sorrendbe kell rakniuk őket. 


Útkeresés a kommunikációban 

Az ismeretek megértése és megosztása. A vizuális munka- 
módszer bevezetése biztosítja a szellemi munkásoknak a 
felmerülő problémák újfajta, kreatív megoldását. Az elfo- 
gadott tudományos álláspont szerint, ha az egyén agyának 
mindkét felét használja (a balt a szöveges, a jobbot a képi 
információk feldolgozásához), akkor gyorsabb a megértés, 
és alaposabban elraktározódnak az információk. A folyama- 
tosan változó tudományos álláspontoktól függetlenül kije- 
lenthetjük, hogy az olyan eszközök használatával, melyek 
igénybe veszik mind a képi, mind a nyelvi felfogóképessé- 
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get, a dolgozók hatékonyabban képesek értelmezni és meg- 
osztani a rendelkezésükre álló információkat. 


A képi gondolkodás gyakran elősegíti a problémamegol- 
dást. Az adatok összegyűjtése és képi formába rendezé- 
se segít elképzelni összetett dolgokat, például létesít- 
mények felügyeleti tervét, hálózati architektúrákat és 
termékfejlesztési életgörbéket. 


Hatáskeltés. A szellemi munkások kezdik belátni, hogy a 
képi üzenetek jobban átjutnak a munkatársakhoz és vásár- 
lókhoz, és szinte áttörnek az információáramlás zűrzavarán. 
A felmérések bebizonyították, hogy a képi anyagot tartal- 
mazó bemutatók 439o-kal meggyőzőbbek az azt nélkülözők- 
nél. Az erős asszociatív elképzelések, melyek a képi kommu- 
nikáció eredményei, 25099-kal jobban megmaradnak az em- 
berek emlékezetében, mint a szóbeli kommunikáció. 
Változások kezelése. A globalizáció, a vállalatok összeolva- 
dása és a folyamatos üzleti átszervezések során a szerveze- 
ti és ügyviteli változások sikeres kommunikálása csökkenti 
a fejetlenséget és az eredménytelenséget. 

A képi gondolkodás gyakran elősegíti a problémamegoldást. Az 
adatok összegyűjtése és képi formába rendezése segít elképzel- 
ni összetett dolgokat, például létesítmények felügyeleti tervét, 
hálózati architektúrákat és termékfejlesztési életgörbéket. A 
szervezeti és üzleti modell diagramok biztosítják a szellemi 
munkásoknak a vállalati fejlődés hatásának és saját feladataik, 
felelősségük változásának megértését és bemutatását. 


1. Or... 


2. The organization chart: 


Jim and Kim work at 
the same level as Sue 


and Lou, who report to 
Ed. Ed works for Chris, 


who manages Jim and 
Kim... 
(on some projects). 





a Ki a főnök? A képi kommunikáció intuitív, nyelvtől 
független, szövegnél hatékonyabb eszköz, mely elősegíti 
az alárendeltségi viszonyok gyors megértését. 


A hatókör megnövelése. A globalizáció a kultúrák közti és a 
földrajzi távolságokat egyaránt áthidalni képes eszközöket igé- 
nyel. A globális kommunikációnak meg kell valósulnia, és gyor- 
sabban kell bonyolódnia, mint eddig bármikor. A képi eszközök 
nagyon leegyszerűsítik a különböző kultúrák közti kommunikáció 
megvalósulását, és segítenek az új és a távoli dolgozóknak a vál- 
lalat munkatempójához való problémamentes alkalmazkodásban. 


A képi kommunikáció működés közben 

A Microsoft Visio 2000 a vizuális munkamódszerek kivitelezésé- 
nek és bevezetésének nélkülözhetetlen alapja. Nyílt architektú- 
rája segítségével a Visio 2000 kielégíti a növekvő nagyvállalatok 
összetett üzembehelyezési és üzemeltetési igényeit. A követke- 
ző három részből álló mintapélda bemutatja, hogy hogyan is nö- 
velik a Visio 2000 kommunikációs eszközei egy éppen megvál- 
tozó vállalaton belül a hatékonyságot és termelékenységet. 
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1. rész: Az egyesülés 

Az Adventure Works és a Fabrikam Inc. elhatározták, hogy 
összevonják erőiket, hogy piacvezetők legyenek a szabadidő- 
ruházat eladásban. Az egyesülés feltételei között szerepel az 
összes alkalmazott megtartása. Mivel jelentős átfedések van- 
nak a munkakörökben és a kötelezettségekben, az alkalma- 
zottak tétovázva haladnak előre a projektekkel, nehogy dup- 
lán végezzék el ugyanazt a munkát. 

A két humánerőforrás csapat összeül, és egyesítik adatbázi- 
saikat. Az így kapott információk felhasználásával automa- 
tikusan létrehozhatnak egy összevont szervezeti diagramot, 
mely tartalmazza az összes dolgozó elérhetőségét, és közzé- 
tehetik az egyesített vállalati intraneten. Az alkalmazottak 
így képesek lesznek azonosítani a velük megegyező munka- 
körben dolgozókat, és látják, kivel kell együtt dolgozniuk. A 
vezetés pedig elkezdhet azon gondolkozni, hogy hogyan 
tudják a legjobban hasznosítani az összevont szaktudást. 





A.esmeesezmtáná ntása szegy 


5 A két humán erőforrás csapat egyesíti adatbázisát, 
hogy elkészülhessen az összevont szervezeti diagram. 


2. rész: A költözés 

A vezetőség úgy határozott, hogy összevonják a két irodát 
is. Az Adventure Works telephelye a külvárosban van, és 
könnyen bérelhetnek az irodájukhoz kapcsolódó további te- 
rületeket. A Fabrikam alkalmazottainak viszont el kell hagy- 
niuk a belvárosi telephelyüket. Az épületek felügyeletének 
vezetője lehetővé teszi a Fabrikam dolgozóinak az új iroda- 
bútor kiválasztását, és új helyük elrendezésének meghatáro- 
zását. A vezető készít egy testreszabott Microsoft Visio 2000 
sablont, mely tartalmazza a megfelelő bútoralakzatokat és 
irodafelszereléseket. Az új iroda Visio 2000-rel készült alap- 
rajzát, melyen ki van jelölve minden alkalmazott helye, köz- 
zéteszi a vállalat belső hálózatán. A rajzra mutató hivatko- 
zásra kattintva az alkalmazottak a számítógépükre telepített 
Visio 2000 segítségével megnyithatják az ábrát. Amikor az 
alkalmazottak kiválasztották a nekik szükséges dolgokat, az 
épületek felügyeletének vezetője lefuttathat egy jelentést a 
kész rajzon, és létrehozhat egy megrendelőlistát, melyen 
szerepel az összes szükséges bútor. Ez a lista az ábrán elhe- 
lyezett bútorokhoz kapcsolódó adatok alapján készül. 
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a A testreszabott bútoralakzat- és irodafelszerelés-sablo- 
nok használatával az alkalmazottak a kívánt elrendezésnek 
megfelelően a helyükre mozgathatják a bútorokat a képer- 
nyőn, majd a megváltoztatott ábrát a hálózatra menthetik. 


3. rész: Az elektronikus kereskedelem kiépítése 

. Az irodákat sikeresen összevonták, és összeálltak a munkacso- 
portok is. A piac alapos elemzése során kiderült, hogy az új 
cég vásárlói közül sokan használják az Internetet. A vezető- 
ség úgy dönt, hogy a meglevő értékesítési csatornákat kibő- 
vítik egy elektronikus kereskedelmi webhellyel. Az Internet 
munkacsoport egy diagram segítségével mutatja be a terve- 
zett elektronikus rendelési folyamatot, hogy elkerülhetők le- 
gyenek a hibák, és a lehető legegyszerűbb legyen a folyamat. 
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a Az eredeti rendeléskezelési diagram az elektronikus 
rendelési folyamat általános ábrázolása, mely segít az 
Internet csapatnak átláthatóvá tenni a folyamatot. Rá- 
jönnek, hogy az ábra nem tartalmazza azokat a vásárló- 
kat, akiknél szükségtelen a fizetőképességet ellenőrizni. 


Az eredeti diagram nem veszi figyelembe, hogy az Interne- 
ten vásárlók között sok olyan lehet, aki a cég törzsvásár- 
lója. Náluk fölösleges a fizetőképesség ellenőrzése, és csak 
lassítaná a rendelési folyamatot. A folyamat ábrázolásának 
segítségével a munkacsoport észreveheti, hogy mely lépé- 
seket kell módosítani, és kialakítható a rendelési folyama- 
tot legjobban elősegítő webhelyszerkezet. Az átalakított 
folyamatábra használható a webhely építőinek és a beszál- 
lítók tájékoztatására is. További folyamatábrák is készül- 
nek, melyek a kereskedelmi folyamatot mutatják be. 
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o Az új folyamatábra megmutatja, hogyan segít az in- 
formációk képi megjelenítése a problémák megoldásá- 
ban, a vállalaton belüli kommunikáció minőségének ja- 
vításában és a fontos folyamatok dokumentálásában. 





Erőteljes eszköz, mely segít az információk jobb megérésé- 
ben és a kommunikáció javításában. 

Egy nemrégiben megjelent tanulmány szerint a Fortune 500 
cégek döntéshozói hangsúlyozták, hogy az egyik legfonto- 
sabb dolog az, hogy az eredmények gyorsan eljussanak hoz- 
zájuk. Az elgondolások, folyamatok és rendszerek átlátásához 
az egyik legjobb módszer azok ábrázolása egy diagramon, 
vagy rajzon. Azoknak a vállalatoknak a szellemi munkásai, 
akik már alkalmazzák a vizuális munkamódszert, alátámaszt- 
hatják ezt az állítást. Az általuk használt eszközöknek támo- 
gatniuk kell a kommunikációnak ezt a módját. Ha az összes 
előnyét figyelembe vesszük, megállapíthatjuk, hogy a Micro- 
soft Visio 2000 platform vitathatatlanul a jelenleg piacon le- 
vő legjobb eszköz a képi kommunikáció megvalósításához. 


Egyszerű használat 

A vállalatoknak olyan eszközökre van szükségük, melyek nem 
nehezítik meg az alkalmazottak munkavégzését. Ezeknek az 
eszközöknek egyszerűnek kell lenni, 
hogy a tapasztalatlan felhasználók 
is kezelni tudják őket, de a tapasz- 
talt felhasználók számára biztosíta- 
niuk kell a legbonyolultabb felada- 
tok elvégzését is. A Visio 2000 ke- 
zelőfelületét úgy tervezték, hogy 
kielégítse ezeket az igényeket. 

A sablonok és minták jó szolgálatot 
tesznek azoknak a felhasználóknak, 
akiknek nem kell vázlatok alapján 
objektumokat készíteni. Az ezeket 
használók egyszerűen, , húzd és ejtsd" (drag and drop) mód- 
szerrel állíthatnak össze az alakzatokból diagramokat. A 
nagyszámú diagramtípus és beépített intelligens objek- 
tum—melyeket SmartShapes szimbólumoknak neveznek— 
lehetővé teszi a felhasználható ábrák egyszerű elkészítését. 


Rugalmasság 

A vállalatok nemcsak azért szabványosítják az asztali gé- 
pek alkalmazáskészletét, hogy egyszerűsítsék a szoftverbe- 
szerzést és az üzembehelyezést, hanem azért is, mert ez 
megkönnyíti a felhasználók képzését, a felhasználók közti 
fájlcserét és a használatot. A Visio 2000 intuitív felhasz- 
nálói felülettel rendelkezik, iparáganként jellemző minták 
és alakzatok ezreit tartalmazza, így biztosítja mind az egy- 
szerű, mind az összetett rajzok készítését. Még a szokatla- 
nul nagy, akár több tízezer objektumból álló rajzok is egy- 
szerűen létrehozhatók és kezelhetők a termék navigációs 
képességeinek (például az automatikus számozásnak és 
egyéb alakzatkezelő eszközöknek) köszönhetően. 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 01. 


140 





41 


OFFicE 2000 pw 


A még nagyobb rugalmasság elérése érdekében a Visio 
2000-be beépítették többféle dokumentumtípus kezelését. 
A saját natív .VSD fájlformátuma mellett a Visio 2000 képes 
kezelni (importálni) más, népszerű rajzolóprogramokkal ké- 
szített rajzokat (például CorelDRAW! 3-7 verziók, a Micro- 
grafx Designer és az ABC Flowcharter bizonyos verziói). Ha 
egy Visio 2000 diagramot más célra akarunk használni, ak- 
kor rengeteg egyéb formátumba (például BMP, GIF, JPEG, 
HTML, és VML - Vector Markup Language) menthetjük el. 

A Visio 2000 Technical Edition képes írni és olvasni a piac- 
vezető .DWG és .DGN CAD (computer-aided design — számí- 
tógéppel támogatott tervezés) fájlformátumokat, ráadásul 
képes átalakítani a statikus CAD objektumokat dinamikus 
SmartShapes szimbólumokká. 


Intelligens funkcionalitás 

A Microsoft Visio 2000 rugalmas megoldás, mely kielégíti a 
nagyvállalati vásárlók folyamatosan változó igényeit. A Vi- 
sio 2000 a robusztus funkcionalitás megtartása mellett vá- 
lik egyre intelligensebbé és gyorsabbá. 

A Visio 2000 talán a leggyorsabban piacra dobott termék, 
elődjéhez képest jobb teljesítményt és skálázhatóságot mu- 
tat. A rajzolási és diagramkészítési feladatok kevesebb idő- 
be telnek, és a meglévő kiegészítő alkalmazások is gyorsab- 
ban futnak. Emellett a javított snap-to (megadott helyekre 
ugrás) és elrendezési vezérlők nagyban meggyorsítják a raj- 
zolási folyamatot. Az új, madártávlati nézet ablak, a gyors 
képcsúsztatási és nagyítási (pan-and-zoom) lehetőségek 
segítségével sokkal jobban kezelhetők a nagy rajzok. 


Internetes és intranetes képességek 

A vállalatok a kommunikáció gyorsítására és új üzleti lehetősé- 
gek kiaknázására használják az Internetet. A Visio 2000 ebben is 
kiváló partner, hiszen az Office család többi tagjához hasonlóan, 
kiváló webes képességekkel rendelkezik (például a kész rajzok 
megosztása, és a rajzokon belül hivatkozások elhelyezése). 

A Visio 2000 diagramjai HTML formátumban is elmenthetők 
(ezután pedig természetesen közzétehetők egy webkiszolgálón, 
és egy egyszerű webböngésző segítségével megtekinthetők). A 
Visio 2000 támogatja a VML (Vector Markup Language — vek- 
torleíró nyelv) formátum használatát, tehát az elkészült rajzok 
ilyen formában is elmenthetők. Miért is jó ez? Azért, mert így 
az Internet Explorer segítségével, a Visio 2000-et megközeli- 
tő rajznézegetési funkciókat kapunk (például nagyítás) . 

A Visio 2000 SmartShapes szimbólumai támogatják a 
beágyazott hivatkozásokat. Bármely alakzatban elhelyezhe- 
tő egy másik , rajzlapon", fájlban, vagy akár weblapon talál- 
ható információra való hivatkozás, ebből következik, hogy a 
Visio 2000-el készített rajzok dinamikussá tehetők. 

Hogy a felhasználónak ne kelljen sokat keresgélnie a frissí- 
téseket, kiegészítéseket, vagy a termékről szóló híreket és új 
információkat, a Visio mindegyik változata tartalmazza az 
adott termék webhelyére mutató hivatkozásokat. Itt letölt- 
hetünk különféle kiegészítéseket, technikai támogatást, sőt 
felhasználói képzést is kaphatunk, tehát minden segítséget 
megkapunk ahhoz, hogy a legtöbbet hozzuk ki a Visio-ból. 
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Jól kidolgozott platform az üzleti megoldásokhoz 

A vállalatok dolgozóinak feladataik megoldására alkalmas 
eszközökkel kell rendelkezni, ha lépést akarnak tartani az 
egyre gyorsuló üzletmenettel. A Microsoft Visio 2000 rugal- 
mas platformot biztosít az asztali gépek testreszabott raj- 
zoló és diagramkészítő megoldásai számára. 


Jól használható megoldások gyors elkészítése 

A testreszabott vállalati megoldások elkészítésére fordítható idő 

és létszám jelentősen lecsökkent az utóbbi években. Amikor a 

vállalatok robusztus és hatékony megoldásokat keresnek problé- 

máik megoldására, előnyben részesítik a , dobozból kivett" alkal- 
mazásokat, mert ezek lehetővé teszik számukra az üzembehelye- 
zés és alkalmazások testreszabásának meggyorsítását. 

Fejlesztői platformként a Visio 2000 egy könnyen bővíthető 

alapot biztosít, melyre a vállalatok meglévő üzleti rendsze- 

reikkel integrált megoldásokat építhetnek (például követelé- 
sek követése, kereskedelmi folyamatok automatizálása, auto- 

matikus időbeosztások elkészítése, adatok képi megjelenítése) . 

Ezek a megoldások nagy értéket képviselhetnek egy vállalat 

számára, ugyanakkor minimális időráfordítással elkészíthetők: 

"0 A legfőbb képesség a testreszabott alakzatok, sablonok 

és minták elkészítésének lehetősége. Minden Visio 2000 

alakzatot paraméterezett képletek írnak le. Ez biztosítja a 

fejlesztőknek az intelligens, adatfüggő alakzatok létreho- 

zását, melyek intuitívan viselkednek a különféle problé- 
mák megoldásakor. Ez a programozás egy számolótáblák- 
hoz hasonló, ShapeSheet nevű környezetben végezhető. 

A Visio 2000 tartalmazza a Microsoft Visual Basic for 

Applications (VBA) 6.0 verzióját. Ez ugyanaz a VBA, 

amely a Microsoft Office 2000 alkalmazásaiban is meg- 

található, és olyan fejlesztői környezetet biztosít, mely 
az egyszerű makrók írásától a teljes alkalmazások írá- 
sáig mindent biztosít. 

2 Ha ez valakinek nem lenne elég, a Visio 2000 tartalmaz- 
za az alakzatok információinak adatbázisokhoz való kap- 
csolását is. Ez azt jelenti, hogy minden Visio 2000 alak- 
zat tartalmazhat adatokat, tehát gyakorlatilag bármi- 
lyen információt, amit a fejlesztő el akar helyezni ben- 
ne. A fejlesztő ODBC-n (Open Database Connectivity) ke- 
resztül kapcsolhatja az adatokat bármilyen ODBC kompa- 
tibilis adatbázishoz. A rugalmasság további fokozásának 
érdekében a fejlesztők arra is használhatják a VBA-t, 
hogy az adatokat bármilyen külső adatbázishoz kapcsol- 
ják, és teljes mértékben szabályozni tudják a Visio 2000 
és az adatbázis közti adatmozgásokat. 


Magasszintű fejlesztési lehetőségek 

A vállalatok üzleti alkalmazás-portfoliójuk összeállításakor 

egyre inkább a , polcról levett" összetevőket keresik. A Vi- 

sio 2000-ben jól kidolgozott, negyedik generációs progra- 

mozói API található, mely kifinomult objektummodellt tar- 

talmaz. Ez biztosítja, hogy a Visio 2000 felhasználásával 

készült egyedi alkalmazások fejlesztésekor ne csak a VBA, 

hanem a Visual Basic, a C--4, a Delphi, a Java, vagy bármely 

más programnyelv is használható legyen. 

A főbb újítások a következők: 

2 Bővített eseménymodell: meghatározott események 
végrehajtásának szabályozása programozással. 

2 Átdolgozott felhasználói felület rendszer: a felület ele- 
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meinek (menük, eszköztárak) alaposabb szabályozása. 
Visio 2000-ben megnyíló felhasználói ablakok: lehető- 
ség egyedi ablakok elhelyezésére a Visio 2000 többdoku- 
mentumos felület (multiple-document interface - MDI) 
keretben. Ez biztosítja a fejlesztőnek az alkalmazástól 
függő ablakok hozzáadását a Visio 2000 felhasználói fe- 
lületéhez, és azt, hogy ezeket a Visio 2000 kezelje. 

-? Teljesítmény: megnövelt teljesítmény, valamint számos 

ShapeSheet és API bővítés. 

Minden Visio 2000 megoldás a végfelhasználók számára 
is elérhető API-kkal és módszerekkel lett kifejlesztve. 


hú 


Egy program az összes diagramkészítési feladathoz 
A vállalatok egyre inkább szabványosítják széles körben 
használt programjaikat. Néhány példa, ahol a Visio 2000 
használatával hatékonyabbá tehetők a vállalati tevékeny- 
ségek: újrahasznosított ismeretek, infrastruktúra felügye- 
let, szoftver- és adatbázis-fejlesztés, üzleti folyamatok ja- 
vítása, minőségbiztosítási rendszerek. 
A Visio 2000 sok diagramfajta elkészítéséhez használható, au- 
.  tomatizálásának lehetősége pedig biztosítja a diagramok ada- 
tokból való létrehozását, valamint információk összegyűjtését 
és adatbázisba mentését. A létrehozható alkalmazások bonyo- 
lultságára maga a Visio 2000 a legjobb példa, amelyet Visio 
technológiával fejlesztettek ki, és azok az alkalmazások, me- 
lyeket független gyártók a Visio 2000 platformon építettek. 


Integráció a nagyvállalati információkkal 

A vállalatok keresik az ERP rendszereikben felhalmozódott 
rengeteg adat felhasználásának módját. A Visio 2000 a leg- 
jobb megoldás arra, hogy ezekből az adatokból használható 
képi információt , varázsoljon", és ezzel jelentést adjon nekik. 
A Visio 2000 például automatikusan képes szervezeti diag- 
ramot készíteni az ERP rendszerben tárolt jelentési struk- 
túrából, vagy adatot nyerhet ki egy Visio 2000 diagramon 
feltüntetett ipari rendszerről, hogy automatikusan anyag- 
számlákat és költségbecsléseket készíthessen. 


Kisebb birtoklási költség 

A legtöbb vállalat célja a legnagyobb érték megszerzése a 
lehető legalacsonyabb áron. Hogy segítse ennek a megva- 
lósítását, a Visio 2000 meglévő és kialakulóban levő szab- 
ványokra épül, ezzel csökkentve a nagyvállalat számára a 
Visio 2000 teljes birtoklási költséget. 

A legtöbb nagyvállalatnál a Visio 2000 szoftvert vagy a köz- 
ponti IT osztály helyezi üzembe és felügyeli, vagy az egyes 
szervezeti egységek alakítanak ki maguknak egyedi beállítá- 
sokat. Az ilyen vállalati környezetben nagy segítséget jelent 
a Visio 2000 rugalmassága és egyszerű telepíthetősége. 


Kisebb telepítési és üzembehelyezési költség 

"0 A Visio 2000 a Microsoft Windows Installer-t használja, 
mely segíti a megfelelő összetevők megfelelő időpont- 
ban történő telepítését. 

"0 A rendszergazdák megadhatják, hogy a Visio 2000 
összetevői vagy fájljai az ügyfélgépeken, vagy a kiszol- 
gálón helyezkedjenek el. Ez jobb erőforrás-kezelést ered- 
ményezhet. 

0 A Visio 2000 telepíthető Windows Terminal Server-re, 
így több ügyfél használhatja egyszerre. Ez a módszer a 
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központosított rendszerfelügyelet miatt csökkenti az 
üzembehelyezési és karbantartási költséget. 


Kisebb támogatási költség 

Egyes felmérések szerint az asztali gépek költségeinek húsz szá- 
zalékát a végfelhasználók támogatásának költségei teszik ki. A 
Visio 2000 kiváló súgója csökkenti a támogatási terheket, mert 
interaktívabb és a beszélt nyelvet is megérti. Emellett a Visio 
2000 felhasználói felülete az Office 2000-éhez hasonló, így az 
Office-t használóknak kevesebb nehézséget fog okozni a Visio 
használata. Az Office 2000-ben alkalmazott megoldásokat (pél- 
dául HTML súgó) integrálták a Visio 2000-be. 


Egyszerű licenszelés 

A Visio 2000 a Microsoft licenszprogramjai keretében vásá- 
rolható meg, melyek egyszerűvé és költséghatékonnyá te- 
szik a nagyvállalatnak a Visio 2000 termékek licenszelését. 
A licenszelésről részletes információ található a [1] címen. 


Tanácsadószolgálat és terméktámogatás 

További erőforrások segítik a Visio 2000 platformra fejlesz- 
tő vállalatokat. A Visio Consulting Services a legjobb Mic- 
rosoft Visio 2000 szakértők tanácsait és tapasztalatát biz- 
tosítja a vásárlóknak. A Microsoft megoldásszállítói is se- 
gítséget nyújthatnak a vállalatoknak testreszabott megol- 
dások elkészítésében. 


Összefoglaló 

A Microsoft Visio 2000 platform a vállalatok alkalmazásait 
olyan nagyvállalati szintű eszközökké változtathatja, me- 
lyek növelik a rugalmasságot és csökkentik a költségeket. 
Olyan funkcionalitást biztosít, mely csökkenti a PC-k bir- 
toklási költségét, egyszerűsíti az alkalmazások használa- 
tát, és az eddigieknél hatékonyabb eszközöket biztosít az 
információk létrehozására, elérésére és cseréjére. 

Mivel kiválóan integrálódik az összes nagyvállalati alkal- 
mazáshoz és erőforráshoz, a Visio 2000 remek platform az 
üzleti megoldások építéséhez. Új, továbbfejlesztett mód- 
szereket tartalmaz, ezzel biztosítva, hogy a vállalat sikere- 
sebb és versenyképesebb legyen. 


A cikkben használt URL-ek: 


[1] http:// www.microsoft.com/shop 


További információk: http://www.microsoft.com/office/visio/ 
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Dupra kv 5 Kérdezz, Felelek! 





DUPLA 





K: Hogy tudnám lementeni az Exchange 5.5 mailboxait? 
Olyasmire gondolok, hogy készülne például egy mailbox- 
név.pst (személyes mappafájlt kellene csinálni minden mail- 
boxból). Megoldható? Mivel, hogyan? 

V: Erre való a Backoffice Resource Kit segédeszköze, a Ma- 
ilbox Migration Tool. Ennek segítségével ugyanis tetszőle- 
ges Exchange Serverek között lehet levelesládákat átmoz- 
gatni, ami ugyan most válasz a kérdésre, de érdemes tud- 
ni, hogy a mozgatáshoz nem kell két futó Exchange Server, 
mivel az átmozgatás PST fájlokon keresztül történik. De ha 
már itt tartunk az eszköz nemcsak a leveleket teszi ki PST- 
be, hanem a szabályokat és a mappahierarchiát is. 

Forrás: NetAcademia Exchange 2000 lista 


K: Hogyan lehet az IIS ,,default virtual SMTP server" könyv- 
tárát megváltoztatni? Ha egy további ,, virtual SMTP Servert" 
veszek fel, ott meg lehet adni, de a default egyből, kérdés 
nélkül az Inetpub alá telepszik. A teljes IIS-t kéne újratele- 
pítenem, hogy rákérdezzen a target directory-ra? 

V: Nem. Ezek az információk az úgynevezett Metabase- 
ben vannak, ami hasonló a regisztrációs adatbázishoz, s 
az IIS itt tárol egy csomó információt önmagáról. (Lásd 
Metabse cikkünket ugyanebben a lapszámban.) Gyárilag 
a Metabase a winntisystem32dinetsrvladminsamples 
könyvtárban lévő scriptekkel módosítható, ami elég kel- 
lemetlen, de szerencsére van grafikus eszköz is, a Meta- 
base Editor! Letöltés az [1] címről. Aki ezt hibátlanul 
begépeli, megérdemli az eszközt!) : 



























BZEZTAZi 218 szIDI21 
Metabase Edit Check Wew Help 
a Bi a] ld Name [/Attibutes [UT DT Í Data a 
8) CI EventManager uj KeyType inh Server St. IlsSmipServer 
1 CI NSADMIN 2) ConnectionTime.. Inh Server D.. 600 
7) CI IMAPASVC eg MaxConnections Server  D... 2000000000 
a £I Loggng aj ServerComment — Inh Server SL.  Defaut SMTPVI 
CI MimeMap ég ServerState Sever D.. 2 
52 a) FiröevÉ d Serverdutostat —Inh Sever D. 1 e. 
B. terve aj ServerBindings —Inh Server  M.. :25. 
ÉLEN SKÉGS ág ClusterEnabled Sever D.. 0 
Ti ád Win32Etor Server D.. 0 
CI Allat úg LogType inh Server D.. 0 
ao as LogFileDírectoy —Inh Server Ex. EAWINNTASyst 
81 (I Domain LogFiePeriod Inh Server D.. 1 
a CI EventManage LogFileTruncate.., . Inh D...  20480000 
A Routings ouzo IPSecuriy inhRet Bi. 1800008020 
XI Sessions AdmináCL Inh Sec e Bi. "Not Displaped" 
MccessSSLFlags Sever D.. 0 
NTAuthenticatia Server St. GSSAPLNTLM 51 
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Forrás: NetAcademia Windows 2000 lista 


K: Nagyon tetszik a Terminal Services, használjuk is rendesen, kü- 
lönösen hasznos a helyi erőforrások , felmeppelése" és a helyi és 
távoli felület közös vágólapja. Már csak egy dolog hiányzik a bol- 
dogságomhoz: fájlokat nem lehetne átvinni a két rendszer között? 
V: A Windows 2000 Resource Kit része az RDPCLIP.EXE. 
kiegészíti a Terminal Services beépített RDP protokollját, 
hogy az képes legyen fájlokat átvinni. Míg az eredeti 
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kiadásban ha az egyik felületen (pl. a távolin) megkísére- 
lünk lemásolni egy fájlt (CTRL-4-C), a másikon semmit sem 
illetszt be a rendszer, addig e kiegészítő telepítése után a 
vágólap komplett fájlokat is át fog vinni. CTRL4C itt, 
CTRL--V ott és kész. A [2] címről letölthető az ingyenes vál- 
tozat - amely az én kísérleteim során csökönyösen kére- 
gette a ResKit CD-t, tehát mégsem ingyenes :-0 

Forrás: NetAcademia Windows 2000 lista 


K: Hogyan lehetne TSOL programból egyértelműen megállapí- 
tani a bejelentkezett felhasználó nevét? 

V: Nincs olyan, hogy egyértelmű, ugyanis az SOL Server fel- 
használói eleve kétfélék lehetnek: Windows fiókok és cso- 
portok valamint SOL felhasználók. Továbbá egy bejelentke- 
zett felhasználó más és más néven szerepelhet az adatbázi- 
sokban, emlékezzünk csak a sa-dbo aliasra. Van egy csomó 
rendszerfüggvény a felhasználó azonosságának megállapítá- 
sára, de mind másra való. A megszokott SUSER NAME() pél- 
dául már semmire, SOL 2000-nél mindig NULL-t ad vissza, 
ne használjuk. Windows hitelesítéssel (egyébként sysadmin- 
ként) bejelentkezve a következő válaszokat kapjuk: 


select user name() 
dbo --az aktuális adatbázis USER-e 
select suser sname() 


NETACADEMIANfm -— A loginnév 
Forrás: NetAcademia SOL 2000 lista 


K: A Security Bulletin által javasolt gyorsjavítások nincsenek 
digitálisan aláírva. Ergo pont a biztonsági patchek hamisít- 
hatók. Ez kicsit fura nemde? 

V: Dede. De a Microsoft javuló tendenciát mutat. Egyik 
listatagunk hívta fel arra a figyelmünket, hogy van már 
olyan hotfix (IE 5.5 SP1 utáni hotfix, letölthető a [3] 
címről) , ami el van látva digitális aláírással. 





kan 2 
Do you want to install and run " Microzoft Intemet Explorer. 
55 Service Pack 1 and Internet Tool" signed on 

11/728/2000 11:20 PM and distibuted by: 





Micsosoít Corporation 


Pubisher authenticity verified by VeriSign Commercial 
Software Publishers CA. 


Caution: Microsoft Corporation asserts that this content is 
sale. You should only install view this content if you trust 
Microsoft Corporation to make that assertion. 





fi Alnays trust content from Microsoft  Goldolatlon 


Yes r "More Info 








Bízzunk benne, hogy a jövőben ez a módszer válik általánossá! 
Forrás: NetAcademia Security lista 
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K: a gépemen lévő Outlook 2000 kicsit furcsán kezd viselked- 
mi... Először úgy töltötte le a leveleim, hogy az összes levél 
subjectje üres volt, a feladás dátuma pedig az épp aktuális 
rendszeridő, a levél tartalma pedig a teljes e-mail (internet 
fejléccel, mindennel együtt). Ezután egyszerűen nem volt haj- 
landó megnyitni az üzeneteket, mondván, hogy sérült a pst 
file, lépjek ki és futtassak egy bizonyos Inbox Repair Toolt... . 
Kérdésem az lenne, hogy mi ez az eszköz, és hol találom? 

V: SCANPST.EXE, és a Microsoft Office 2000 legelső CD-jén 
található. A PST fájl belső felépítése hasonló a JET adat- 
bázisokhoz - pointerek mindenfelé. Ha ez elromlik, akkor 
az Outlook sem tehet mást, mint hogy zagyvalékot mutat. 
Az Inbox Repair Tool azonban nem csodaeszköz. Láttam 
már olyat, hogy a javítása annyiból állt, hogy üresre radí- 
rozta a PST fájlt. Használata előtt illik menteni! 

Forrás: NetAcademia Exchange 2000 lista 


K: Hogyan lehetne weblapról tetszőleges címről/címre leve- 

let írni? A lehető legegyszerűbb megoldás érdekelne! 

V: Egyszerű és rugalmas - ez az ASP! Az alábbi négyso- 

ros programka kerüljön bele egy KULDUNK.ASP nevű 
" weblapba, s az meg egy olyan könyvtárba, ahol a script- 

végrehajtási jog engedélyezve van: 


A cikkben található URL-ek: 


DUPLA KV DUPLA KV 
Zhtml: 
ez 
Set objNewMail— 
4 Server.CreateObject("CDONTS.NewMail") 
objNewMail.Send Reguest(" feladó"), 
3 Reguest("cimzett"), Reguest("targy"), 
4 Reguest("level") 
Set objNewMail - Nothing 
" canNOT reuse it for another message 
sz 
Kész. 


€/htmlz 


Ezt azután a következőképpen kell meghívni: [4]. Termé- 
szetesen a gyakorlottabbak felismerték, hogy itt a CDONTS 
könyvtár NewMail objektumát babráltuk. Ez pont arra való, 
hogy a lehető legkevesebb macerával lehessen programból 
levelet írni. (Legsikeresebben akkor használhatjuk, ha a 
webkiszolgálón fut egy SMTP szolgáltatás is, mert akkor az 
leveszi a levélküldés terhét a MAPI kliens válláról — erről a 
témáról az ASP suli című cikksorozatunk egy későbbi részé- 
ben részletesebben is beszélünk majd. — [mICK]) Természe- 
tesen a módszer bonyolultabb levelek megírására is alkal- 
mas, hisz az objektumnak nem csak ez a négy-öt paramé- 
tere van. Részletesebben az [5] címen olvashatunk róla. 
Forrás: NetAcademia MsDev lista 





[1] http://support.microsoft.com/support/kb/articles/0232/0/68.ASP?LN-EN-US8SD-gn8.FR-O 

[2] http://www.microsoft.com/windows2000/library/resources/reskit/tools/hotfixes/rdpclip-o.asp 

[3] http://www.microsoft.com/windows/ie/download/critical/g279328/default.asp 

[4] KULDUNK.ASP?felado-akarki(2aa.hugcimzett-marcellf onetacademia.net8targy-akarmiglevel-szoveg 
[5] http://msdn.microsoft.com/library/psdk/cdo/ denali newmail object cdonts library .htm 





Olvasóinkra hallgatva megkönnyítettük a levelezési listákra történő feliratkozást. 
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BILL GATES MONDJA... 


A haladás csak 


A napi munkám egy része előrejelzések készítése, hogy ezek 
alapján tudjunk cselekedni. Jobb vagyok a jövőbeli trendek 
előrejelzésében, mint annak meghatározásában, hogy az adott 
technológiák mikor terjednek el széles körben. Az időzítés előre- 
jelzése nehéz, ahogy azt pályám is mutatja. 

Például az 1980-as évek elején megjósoltam, hogy a grafikus 
felhasználói felület (melyet először a Xerox fejlesztett ki, és 
később az Apple Macintosh és a Microsoft Windows tette népsze- 
rűvé) lesz a fő felület az ember és a számítógép kapcsolatában. 
A jóslat helyes volt, de több évet vett igénybe, mint gondoltam. 
1986-ban úgy gondoltam, hogy a CD-ROM meghajtók nagyon 
rövid időn belül általános célúak lesznek. Igazam volt abban, 
hogy a nagy tárolókapacitású lemezek általánossá válnak, de túl 
optimista voltam azzal kapcsolatban, hogy ez mikor történik meg. 
A kilencvenes évek elején azt jósoltam, hogy az interak- 
tív hálózatok fogják eljuttatni az információkat az 
emberek számítógépeire, televízióiba és egyéb informá- 
ciókezelő eszközeire. Ezt , kéznél levő információ"-ként 
emlegettem, de tévesen ítéltem meg ennek formáját, és 
gyorsan kellett reagálnom, amikor az Internet népsze- 
rűsége 1995-ben elérte a kritikus tömeget. 

Nemrégiben, 1997. elején 15 előrejelzést mondtam arra az 
évre. Tíz igaz lett, például az is, hogy jól használható PC-k 
kaphatók lesznek 1000 USD alatti áron. Öt túl optimistának 
bizonyult, de még mindig bízom benne, hogy megvalósulnak 
- csak idő kérdése. 

1998. elején két új előrejelzést tettem. Azt jósoltam, hogy az 
év második felében a DVD és a DSL fontossá válik. Ezek a 
technológiák fontossá váltak az elmúlt hónapokban, de beval- 
lom, nem érték el azt a népszerűséget, amire számítottam. 

A DVD Digital Versatile Disk-et (általános célú digitális 
lemezt) jelent, bár eredetileg Digital Video Disk-nek hívták. 
A DVD tulajdonképpen a CD-ROM utódja, és úgy is néz ki, 
mint egy CD-ROM. Még a CD-ROM-ok és audio CD-k is 
olvashatók a DVD meghajtóval. 

A különbség az, hogy a DVD a CD-ROM-on tárolható informá- 
ciómennyiség többszörösét képes tárolni, vagyis egyetlen 
lemezen elfér egy VHS-nél jobb minőségű kétórás film. Egy 
DVD meghajtóval felszerelt PC segítségével a film lejátszható 
a gép saját képernyőjén, vagy akár a TV-n is, egy DVD-s lap- 
top segítségével pedig akár a repülőn is nézhetünk filmet. 
Tudtam, hogy 1998. nagy részében még kevés DVD-t fognak 
eladni, de azt hittem, mostanra nagy áttörés lesz ezen a 
téren. Túl optimista voltam. 

A DVD meghajtók kezdenek feltűnni a csúcskategóriás PC-kben, 
és az új PC-k kiegészítőiként. Egy DVD meghajtó általában 50 
és 200 dollár közötti többletköltséget jelent, és a CD-ROM 
meghajtót váltja ki. Én a DVD megvásárlását javaslom, bár 
egyelőre még kevés szoftver jött ki DVD-n, de vannak figyelem- 
reméltó kivételek. Egyre több film vásárolható meg, néhány 
játékot és referenciamunkát kiadnak DVD-n. A National 
Geographic az elmúlt 108 év folyóiratait egy olyan DVD cso- 
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idő kérdése 
magban adta ki, mely elfér a kezemben. A DVD -ken a szöveg- 
en kívül több mint 180.000 fénykép van. 

A másik rövidítés, a DSL Digital Subscriber Line-t (digitális 
előfizetői vonal) jelent. Ez egy olyan technológia, amely 
lehetővé teszi, hogy nagy mennyiségű digitális adat legyen 
átvihető a hagyományos telefonvonalakon. 

A DSL próbaüzemei már folyamatban vannak az Egyesült 
Államokban, de 1998. vége előtt nem lesz széles körben 
hozzáférhető a szolgáltatás" mondtam 1998 elején. 

Ismét túl optimista voltam. A DSL üzembe-helyezése néhány 
helyen folyamatban van, és vannak rajongói, akik szeretik a gyors 
Internet elérést, de a telefontársaságok többet kérnek a szolgál- 
tatásért, mint amire számítottam, és ez akadályozza a DSL elter- 
jedését. Ugyanígy nehezíti a kábelmodemek terjedése, amelyek a 
telefonvonal helyett a kábeltelevízió hálózaton keresztül biztosí- 
tanak nagysebességű Internet elérést. Ennek eredményeként a 
DSL jelentőssége sokkal kisebb, mint amire számítottam. 
Szerencsére néhány találmány gyorsabban népszerűvé 
válik, mint ahogy gondolnám. Van erre egy remek példám, 
ami 1998-ban történt. 

Év elején azt hittem, hogy a nyomtatott szöveggel 
versenyképes felbontású szöveg megjelenítésére képes sík 
képernyő megvalósítására még legalább hat évet kell 
várnom. Alig vártam azt a napot, amikor az emberek kön- 
nyű eszközökön lesznek képesek magukkal vinni számtalan 
újságot, könyvet, vagy akár filmet is. 

Most, nagy meglepetésemre úgy tűnik, hogy csak két évet 
kell várnom! A Microsoft kutatói ugyanis néhány hónapja 
bemutattak egy ClearType-nak nevezett technológiát, amely 
lehetővé teszi a szöveg LCD képernyőn való igen jó minőségű 
megjelenítését. Ránéztem a képernyőre, és azt mondtam 
magamban, hogy ezt képes lennék egész nap olvasni! " 

A ClearType a gyengém, mert arra számítottam, hogy hard- 
verfejlesztések szükségesek ahhoz, hogy az LCD kijelzők 
képesek legyenek a szöveg valóban éles megjelenítésére. 
De a ClearType tisztán szoftveres megoldás, amely szük- 
ségtelenné teszi új hardver kifejlesztését. A meglevő lap- 
topok Cleartype-ban fogják megjeleníteni a szöveget, amint 
a szoftver az operációs rendszerbe integrálva lesz. 

Ahogy új év kezdődik és lenézek az útra, kicsinek és 
lelkesnek érzem magam. Kicsinek, mert képtelen vagyok 
megjósolni az új technológiák (például DVD és DSL) elter- 
jedésének ütemét. Lelkesnek az iparág teljes fejlődési 
üteme miatt, amely megállíthatatlanul halad előre, megvál- 
toztatva életmódunkat és munkahelyünket. 

Az idén óvatos leszek, és csak egyvalamit jósolok, de ez biz- 
tos: A jó szoftverek, melyeket nagyon nehéz létrehozni, 
egyre fontosabbak lesznek a jövőben. A részletek homá- 
lyosak lehetnek, de a teljes kép olyan éles, mint a ClearType. 
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Feltöoörhetetlen 
hálózatról (C2)? 





Elérhetetlen, de megközelíthető célok. Az első kettő elérésében sajnos nem segít- 
hetünk. De a harmadik cél megközelítésében sokat tehetünk Önért. Világszínvonalú, 
egyedi Security tanfolyamainkon megtudhatja, mitől döglik a hacker! 


1. Biztonsági technológiák 3. Hálózatunk védelme a támadásokkal szemben 
rendszergazdáknak, 3 nap biztonsággal foglalkozó szakembereknek, 3 nap 
o Titkosítási algoritmusok (DES, RSA, MD5 stb.) elmélete és gyakorlata e  Kalóz-eszközkészlet (Denial Of Service, Buffer 
s Az authentikáció biztonsága (Kerberos, NTLM, NTLMv2) Overrun, hálózatelemzés, trójai falovak, vírusok, jelszófeltörés, hátsó ajtók) 
o — A nyílt kulcsú titkosítási technológia nagyvállalati, gyakorlati alkalmazása s — A Windows 2000 biztonsági elemei (fájlrendszerek, regisztrációs adat- 
(Certificate Server, SmartCard, biometrikus azonosítás) bázis, hálózati adatforgalom) 
e — Biztonságot növelő technológiák bevezetése (IPSec, VPN, LZTP. Encrypting e Védekezés: tűzfalak, proxyk 
File System stb.) e — Aktív védekezés: Intrusion Detection 
4. Programozzunk biztonságosan! 
2. Biztonságos levelezőrendszer kialakítása MS Exchange alapokon programozók számára, 3 nap 
gyakorlott Exchange endszergazdák számára, 3 nap e Elmélet: védett mód, kernel, memóriakezelés 
e Titkosítás és digitális aláírás az elektronikus levelezésben (S/MIME) e Programozási gyakorlatok, rosszul és jól megírt kódok 
s — Az Exchange Server védelme, adminisztratív szerepek, jogosultságok, s — A Buffer overrun hatásai user és (app es service)--kernel módban 
mentés, visszaállítás, journaling e — RFC implementation errors 
e tűzfal vs. Exchange Server, SMTP relay beállítások, spam védelem, SSL, s — JAVA, ActriveX, homokozó, scriptek 
TSL, nyílt kulcsú titkosítás felhasználása, MAPI, POP3, IMAP, OWA, LDAP e — Worm vírusok elemzése (lloveyou) 
protokollok veszélyei. 9. CryptoAPI, Smart Card API 


A legjobbakat tanítjuk. 
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